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Preface  to  the  First  Edition 


This  document  defines  DIANA,  an  intermediate  form  of  Ada  [7]  programs  that 
is  especially  suitable  for  communication  between  the  Front  and  Back  Ends  of  Ada 
compilers.  It  is  based  on  the  Formal  Definition  of  Ada  [6]  and  resulted  from 
the  merger  of  the  best  aspects  of  two  previous  proposals:  AIDA  [4,  10]  and  TCOL 
[2],  Although  DIANA  is  primarily  intended  as  an  interface  between  the  parts  of 
a  compiler,  it  is  also  suitable  for  other  programming  support  tools  and 
carefully  retains  the  structure  of  the  original  source  program. 

The  definition  of  DIANA  given  here  is  expressed  in  another  notation,  lOL, 
that  is  formally  defined  in  a  separate  document  [9].  The  present  document  is, 
however,  completely  self-contained;  those  aspects  of  IDL  that  are  needed  for  the 
DIANA  definition  are  informally  described  before  they  are  used.  Interested 
readers  should  consult  the  IDL  formal  description  either  if  they  are  concerned 
with  either  a  more  precise  definition  of  the  notation  or  if  they  need  to  define 
other  data  structures  in  an  Ada  support  environment.  In  particular,  implemen¬ 
tors  may  need  to  extend  DIANA  in  various  ways  for  use  with  the  tools  in  a 
specific  environment  and  the  IDL  document  provides  information  on  how  this  may 
be  done. 

This  version  of  DIANA  has  been  "frozen"  to  meet  the  needs  of  several  groups 
who  require  a  stable  definition  in  a  very  short  timeframe.  We  invite  comments 
and  criticisms  for  a  longer-term  review.  We  expect  to  re-evaluate  DIANA  after 
some  practical  experience  with  using  it  has  been  accumulated. 
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Preface  To  The  Second  Edition 


Since  first  publication  of  the  DIANA  Reference  Manual  in  March,  1981, 
further  developments  in  connection  with  Ada  and  DIANA  have  required  revision  of 
DIANA.  These  developments  include  the  following: 

0  The  original  DIANA  design  was  based  on  Ada  as  defined  in  the  July  1980 
Ada  Language  Reference  Manual  [7],  referred  to  hereafter  as  Ada-80;  the 
present  revision  is  based  on  Ada  as  defined  in  the  July  1982  Ada  LRM 
[8],  referred  to  hereafter  as  Ada-82. 

0  Experience  with  use  of  DIANA  has  revealed  errors  and  flaws  in  the 
original  design;  these  have  been  corrected. 


This  publication  reflects  our  best  efforts  to  cope  with  the  conflicting 
pressures  on  us  both  to  impact  minimally  on  existing  implementations  and  to 
create  a  logically  defensible  design. 

Tartan  Laboratories  Inc.  invites  any  further  comments  and  crUicisms  C' 
DIANA  in  general,  and  this  version  of  the  reference  manual  in  parf'cuia’'.  An_, 
correspondence  may  be  sent  via  ARPANet  mail  to  Diana-Query@USC-ECLB.  Pape''  mail 
may  be  sent  to 

DIANA  Manual 

Tartan  Laboratories  Inc. 

477  Melwood  Avenue 

Pittsburgh  PA  15213 


We  believe  the  changes  made  to  DIANA  make  no  undue  constraint  on  any  DIANA 
users  or  potential  DIANA  users,  and  we  wish  to  hear  from  those  who  perceive  an_^ 
of  these  changes  to  be  a  problem. 


Preface  To  This  Edition 


This  is  a  draft  revision  of  the  DIANA  Reference  Manual. 


Experienc**  ,.ch  DIANA  has  revealed  weaknesses  both  in  the  definition  of 
DIANA  and  in  the  DIANA  Reference  Manual.  This  draft  revision  incorporates 
changes  in  both  areas. 


Changes  to  the  definition  of  DIANA  include: 

0  Overhauling  the  representation  of  types  and  subtypes  to  accord  better 
with  the  definition  of  subtypes  in  Ada. 

0  "Partitioning"  the  DIANA  so  that  any  node  or  class  (except  the  node 
void)  is  directly  a  member  of  no  more  than  one  class. 

0  "Hoisting"  attributes  to  the  highest  appropriate  class. 

0  Otherwise  regularizing  the  nomenclature  of  classes,  nodes,  and 
attributes. 


Changes  to  the  DIANA  Reference  Manual  include: 

0  Separation  of  semantic  specification  from  rationale. 

0  Systematic  coverage  of  static  semantics  of  DIANA. 

0  Inclusion  of  hierarchical  diagrams  providing  a  pictorial  representat ' on 
of  class-membership  relations. 

0  Inclusion  of  several  substantial  examples. 

0  Inclusion  of  a  cross-reference  index  of  nodes  and  attributes. 


Chapter  7,  External  Representation  of  DIANA,  and  Chaoter  8,  ’’’he  DIan-'- 

Package  in  Ada,  are  incomplete  in  this  draft. 

Intermetrics,  Inc.  invites  any  further  comments  and  criticisms  on  DIANA  ’n 
general,  and  this  draft  version  of  the  reference  manual  in  particular.  Any 
correspondence  may  be  sent  via  ARPANet  mail  to  DIANA-QUERY@USC- ISIF .  Paper  mail 
may  be  sent  to 

DIANA  Maintenance 

Intermetrics,  Inc. 

4733  Bethesda  Ave. 

Bethesda,  MD  ?0814 


CHAPTER  1 
INTRODUCTION 


The  purpose  of  standardization  is 
to  aid  the  creative  craftsman,  not 
enforce  the  common  mediocrity  [11]. 
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1.1  THE  DESIGN  OF  DIANA 

In  a  programming  environmer  such  as  that  envisioned  for  Ada(l),  there  will 
be  a  number  of  tools  --  formatters  (pretty  printers),  language-oriented  editors, 
cross-reference  generators,  test-case  generators,  etc.  In  general,  the  input 
and  output  of  these  tools  is  NOT  the  source  text  of  the  program  being  developed; 
instead  it  is  some  intermediate  form  that  has  been  produced  by  another  tool  in 
the  environment.  This  document  defines  DIANA,  Descriptive  Intermediate 
Attributed  Notation  for  Ada.  DIANA  is  an  intermediate  form  of  Ada  programs 
which  has  been  designed  to  be  especially  suitable  for  communication  between  two 
essential  tools  --  the  Front  and  Back  Ends  of  a  compiler  --  but  also  to  be 
suitable  for  use  by  other  tools  in  an  Ada  support  environment.  DIANA  encodes 
the  results  of  lexical,  syntactic  and  STATIC  semantic  analysis,  but  it  does  NOT 
include  the  results  of  DYNAMIC  semantic  analysis,  of  optimizat'on,  or  of  code 
generation. 

DIANA  is  an  abstract  data  type.  The  DIANA  representation  of  a  particular 
Ada  program  is  an  instance  of  this  abstract  type.  As  with  all  abstract  types, 
DIANA  defines  a  set  of  operations  that  provide  the  only  way  in  which  instances 
of  the  type  can  be  examined  or  modified.  The  actual  data  or  file  structures 
used  to  represent  the  type  are  hidden  by  these  operations,  in  tne  sense  that  the 
implementation  of  a  private  type  in  Ada  is  hidden. 

References  may  be  made  to  a  DIANA  "tree",  "abstract  syntax  tree",  or 
"attributed  parse  tree";  similarly,  references  may  be  made  to  "nodes"  in  these 
trees.  In  the  context  of  DIANA  as  an  abstract  data  type,  it  is  important  to 
appreciate  the  implications  of  such  terms.  This  terminology  does  NOT  imply  that 
the  data  structure  used  to  implement  DIANA  is  necessarily  a  tree  using  pointers, 
etc.  Rather,  the  notion  of  attributed  trees  serves  as  the  abstract  model  for 
the  definition  of  DIANA. 

■^he  following  princ  :les  governed  the  original  design  of  DIANA; 

0  DIANA  should  be  representation-independent.  An  effort  was  mace  to 

avoid  implying  any  particular  implementation  for  the  DIANA  abstract 

type.  Implementation-specific  information  (such  as  a  value  on  the 

target  machine)  is  represented  in  DIANA  by  other  abstract  types  which 
must  be  supplied  by  each  implementation.  In  addition,  DIANA  may  be 

extended  or  contracted  to  cater  to  implementation-specific  purposes. 

0  DIANA  should  be  suitable  for  various  kinds  of  processing.  Although  the 
primary  purpose  of  DIANA  is  communication  between  the  Front  and  Back 
Ends  of  compilers,  other  environment  tools  should  be  able  to  use  it  as 
well.  The  needs  of  such  programs  were  considered  carefully. 

0  DIANA  should  be  efficiently  implementable.  DIANA  is  intended  to  be 

used;  hence  it  was  necessary  to  consider  issues  such  as  size  and 
processing  speed. 

0  The  DIANA  description  and  notation  should  be  regular.  Consistency  in 
these  areas  is  essential  to  both  understanding  and  processing. 


(1)  Ada  is  a  registered  trademark  of  the  U.S.  Department  of  Defense. 
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Although  DIANA  is  representation-independent,  there  must  be  at  least  one 
form  of  the  DIANA  representation  that  can  be  communicated  between  computing 
systems.  Chapter  6  defines  an  externally  visible  ASCII  form  of  the  DIANA 
representation  of  an  Ada  program.  In  this  form,  the  DIANA  representation  can  be 
communicated  between  arbitrary  environment  tools  and  even  between  arbitrary 
computing  systems.  The  form  may  also  be  useful  during  the  development  of  the 
tools  themselves. 
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1.2  THE  DEFINITION  OF  THE  DIANA  OPERATIONS 

Every  object  of  type  DIANA  Is  the  representation  of  some  specific  Ada 
program  (or  portion  of  an  Ada  program).  A  minimum  set  of  operations  on  the 
DIANA  type  must  provide  the  ability  to: 

0  determine  the  type  of  a  given  object  (in  DIANA  terms,  the  object's  node 
type). 

0  obtain  the  value  of  a  specific  attribute  of  a  node. 

0  build  a  node  from  its  constituent  parts. 

0  determine  whether  or  not  a  given  pair  of  instances  of  a  DIANA  type  are 
in  fact  the  same  instance,  as  opposed  to  equivalent  ones.  For  the 
scalar  types  (Integer  and  Boolean),  no  distinction  is  drawn  between 
equality  and  equivalence. 

0  assign  a  specific  node  to  a  variable,  or  a  specific  scalar  value  to  a 
scalar  variable. 

0  set  the  value  of  an  attribute  of  a  given  node. 


The  sequence  type  Seq  Of  can  be  considered  as  a  built-in  type  that  has  a 
few  special  operators.  The  operators  defined  for  a  sequence  type  allow  an 
implementation  to: 

0  create  a  sequence  of  a  given  type 
0  determine  whether  or  not  a  sequence  is  empty 
0  select  an  element  of  a  sequence 
0  add  an  element  to  a  sequence 
0  remove  an  element  from  a  sequence 

0  compare  two  sequences  to  see  if  they  are  the  same  sequence 
0  assign  a  sequence  to  a  variable  of  a  sequence  type 
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1.3  THE  DEFINITION  OF  A  DIANA  USER 

Inasmuch  as  DIANA  is  an  abstract  data  type,  there  is  no  need  that  it  be 
implemented  in  any  particular  way.  Additionally,  because  DIANA  is  extendable,  a 
particular  implementation  may  choose  to  use  a  superset  of  the  DIANA  defined  in 
this  reference  manual.  In  the  face  of  innumerable  variations  on  the  same  theme, 
it  is  appropriate  to  offer  a  definition  of  what  it  means  to  "use"  DIANA.  Since 
it  makes  sense  to  consider  DIANA  only  at  the  interfaces,  two  types  of  DIANA 
users  are  considered:  those  which  "produce"  DIANA,  and  those  that  "consume"  it. 
These  aspects  are  considered  in  turn: 

0  producer 

In  order  for  a  program  to  be  considered  a  DIANA  producer,  it  must 
produce  as  output  a  structure  that  includes  all  of  the  information 
contained  in  DIANA  as  defined  in  this  document.  Every  attribute 
defined  herein  must  be  present,  and  each  attribute  must  have  the  value 
defined  for  correct  DIANA  and  may  not  have  any  other  value.  This 
requirement  means,  for  example,  that  additional  values,  such  as  the 
evaluation  of  ncn-static  expressions,  may  not  be  represented  using  the 
DIANA-def ined  attributes.  An  implementation  is  not  prevented  from 
defining  additional  attributes,  and  in  fact  it  is  expected  that  most 
DIANA  producers  will  also  produce  additional  attributes. 

There  is  an  additional  requirement  on  a  DIANA  producer:  The  DIANA 
structure  must  have  the  property  that  it  could  have  been  produced  from 
a  legal  Ada  program.  This  requirement  is  likely  to  impinge  most 
strongly  on  a  tool  other  than  a  compiler  Front  End  that  produces  DIANA. 
As  an  example  of  this  requirement,  in  an  arithmetic  expression,  an 
offspring  of  a  mutipl ication  could  not  be  an  addition  but  would  instead 
have  to  be  a  parenthesized  node  whose  offspring  was  the  addition,  since 
Ada's  parsing  rules  require  the  parentheses.  The  motivation  for  this 
requirement  is  to  ease  the  construction  of  a  DIANA  consumer,  since  the 
task  of  designing  a  consumer  is  completely  open-ended  unless  it  can 
make  some  reasonable  assumptions  about  its  input. 

0  consumer 

In  order  for  a  program  to  be  considered  a  DIANA  consumer,  it  must 
depend  on  no  more  than  DIANA  as  defined  herein  for  the  representation 
of  an  Ada  program.  This  definition  does  not  prevent  a  consumer  from 
requiring  other  kinds  of  input  (such  as  information  about  the  library, 
which  is  not  represented  in  DIANA);  however,  the  DIANA  structure  must 
be  the  only  form  of  representation  for  an  Ada  program.  This 
restriction  does  not  prevent  a  consumer  from  being  able  to  take 
advantage  of  additional  attributes  that  may  be  defined  in  an 
implementation;  however,  the  consumer  must  also  be  able  to  accept  input 
that  does  not  have  these  additional  attributes.  It  is  also  incorrect 
for  a  program  to  expect  attributes  defined  herein  to  have  values  that 
are  not  here  specified.  For  example,  it  is  wrong  for  a  program  to 
expect  the  attribute  sm  value  to  contain  values  of  expressions  that  are 
not  static. 
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There  are  twc  attributes  that  are  defined  herein  that  are  NOT  required  to 
be  supported  by  a  DIANA  user:  Ix  comments  and  lx  srcpos.  These  attributes  are 
too  implementation-specific  to  be  required  for  all  DIANA  users. 

It  should  be  noted  that  the  definition  of  a  producer  and  that  of  a  consumer 
are  not  mutually  exclusive;  for  example,  a  compiler  Front  End  that  produces 
DIANA  may  also  read  DIANA  for  separate  compilation  purposes. 

Having  defined  a  DIANA  producer  and  a  DIANA  consumer,  it  is  now  possible  to 
specify  the  requirements  for  a  DIANA  user.  It  is  not  proper  to  claim  that  a 
given  implementation  uses  DIANA  unless  EITHER  it  meets  the  following  two 
criteria: 

0  It  must  be  able  to  read  and/or  write  (as  appropriate)  the  external  form 
of  DIANA  defined  in  Chapter  6  of  this  document. 

0  The  DIANA  that  is  read/written  must  be  either  the  output  of  a  DIANA 
producer  or  suitable  input  for  a  DIANA  consumer,  as  specified  in  this 
section. 

OR  it  meets  this  criterion: 
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1.4  THE  STRUCTURE  OF  THIS  DOCUMENT 

As  previously  stated,  DIANA  is  an  abstract  data  type  that  can  be  modeled  as 
an  attributed  tree.  This  document  defines  both  the  domain  and  the  operations  of 
this  abstract  type.  The  domain  of  the  DIANA  type  is  a  subset  of  the 
(mathematical)  domain  known  as  attributed  trees.  In  order  to  specify  this 
subset  precisely  a  subset  of  a  notation  called  lOL  [9]  is  used.  A  knowledge  of 
IDL  is  necessary  to  read  or  understand  this  document.  Chapter  2  consists  of  the 
IDL  description  of  the  DIANA  domain,  organized  in  the  same  manner  as  the  Ada 
Reference  Manual.  The  DIANA  operations  are  described  in  section  1.2. 

Though  the  IDL  description  of  DIANA  may  suffice  to  describe  the  structure 
of  DIANA,  it  does  not  convey  the  full  semantics  of  that  structure.  For  example, 
in  certain  cases  the  set  of  allowed  values  of  an  attribute  may  be  a  subset  of 
the  values  belonging  to  the  type  of  the  attribute  (although  the  IDL  language 
would  permit  the  definition  of  a  subclass  in  such  cases,  to  do  so  would 
undoubtedly  disrupt  the  hierarchy  and  cause  such  a  proliferation  of  subclasses 
that  DIANA  would  be  almost  impossible  to  understand).  In  addition,  the  IDL  does 
not  specify  the  instances  in  which  two  attributes  must  denote  the  same  node. 
Restrictions  such  as  those  described  above  are  given  in  the  semantic 
specification  of  DIANA,  the  third  chapter  of  this  document. 

Chapter  4  is  a  rationale  for  the  design  of  DIANA.  While  the  semantic 
specification  is  organized  according  to  the  class  structure  of  DIANA,  the 
rationale  is  composed  of  sections  dealing  with  different  semantic  concepts  which 
are  not  necessarily  applicable  to  any  one  DIANA  class. 

Chapter  5  contains  examples  of  various  kinds  of  DIANA  structures.  Each 
example  contains  a  segment  of  Ada  code  and  an  illustration  of  the  resulting 
DIANA  structure.  , 

Chapter  6  describes  the  external  form  of  DIANA,  an  ASCII  representation 
suitable  for  communication  between  different  computing  systems. 

Chapter  7  consists  of  a  package  specification  for  the  DIANA  interface, 
written  in  Ada. 

Appendix  A  is  a  cross-reference  guide  for  the  nodes,  classes  and  attributes 
of  DIANA. 

Appendix  B  is  a  list  of  references. 


1.4.1  NOTATION 

To  assist  the  reader  in  understanding  this  material,  certain  typographic 
and  notational  conventions  are  followed  consistently  throughout  this  document, 
as  illustrated  in  Figure  1-1. 
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DECL 

constant_1d 
sill  exp  type 
Type^ 

"is" 


IDL  Class  name 
IDLnode  name 
IDL  attribute 
IDL  reserved  word 
Ada  reserved  word 


Figure  1-1.  Typographic  and  Notational  Conventions  Used  in  this  Document. 


These  conventions  include: 


0  The  appearance  of  class  names,  node  names,  and  attribute  names  IN  THE 
TEXT  are  distinguished  by  the  following  typographic  conventions:  class 
and  node  names  are  bold-faced,  and  attribute  names  are  underlined. 
These  conventions  are  not  followed  in  the  IDL  specification,  the 
diagrams,  or  the  cross-reference  guide. 

0  Ada  reserved  words  appear  in  quotes. 

0  IDL  reserved  words  appear  in  lower-case  letters,  except  for  the  first 

letter,  which  is  capitalized. 

0  Class  names  appear  in  all  upper-case  letters. 

0  node  names  appear  in  all  lower-case  letters. 

0  attribute  names  appear  in  all  lower  case  letters,  with  one  of  the 
prefixes  defined  below. 

0  There  are  four  kinds  of  attributes  defined  in  DIANA:  structural, 

lexical,  semantic,  and  code.  The  names  of  these  attributes  are 

lexically  distinguished  in  the  definition  by  the  following  prefixes: 

Structural  attributes  define  the  abstract  syntax  tree  of  an  Ada 
program. 

+  1x_ 

Lexical  attributes  provide  information  about  the  source  form  of  the 
program,  such  as  the  spelling  of  identifiers,  or  position  in  tne 
source  file. 

+  Slll_ 

Semantic  attributes  encode  the  results  of  semantic  analysis  --  type 
and  overload  resolution,  for  example. 

+  cd__ 

Code  attributes  provide  information  from  representation 
specifications  that  must  be  observed  by  the  Back  End. 


0  A  class  name  or  node  name  ending  in  '_s'  is  always  a  sequence  of  what 
comes  before  the  (if  the  prefix  is  extremely  long  it  may  be 

slightly  shortened  in  the  sequence  name).  Thus  the  reader  can  be  sure 
on  seeing  exp_s  that  the  definition 
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exp_s  =>  as_list:  Seq  Of  EXP; 

appears  somewhere. 

0  A  class  name  ending  in  '_ELEM'  contains  both  the  node  or  class  denoted 
by  the  prefix  of  the  class  name  and  a  node  representing  a  pragma.  The 
name  of  the  node  representing  the  pragma  consists  of  the  prefix  of  the 
class  name  and  the  suffix  '_pragma'.  Hence  the  reader  knows  that  for 
the  class  name  STM_ELEM  the  following  definition  exists 

STM_ELEM  ::=  STM  I  stm_pragma; 


Throughout  the  remainder  of  this  document  all  references  to  the  Ada 
Reference  Manual  (ANSI/MIL-STD-1815A-1983)  will  have  the  following  form:  [ARM, 
section  number]. 


CHAPTER  2 

IDL  SPECIFICATION 
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This  chapter  contains  the  IDL  description  of  DIANA.  It  is  organized  in  a 
manner  that  parallels  the  Ada  Reference  Manual  --  each  section  contains  the 
corresponding  segment  of  Ada  syntax  along  with  the  related  IDL  definitions.  In 
some  cases  a  section  does  not  contain  any  IDL  definitions  because  that 
particular  construct  is  represented  by  a  node  or  class  which  also  represents 
another  construct,  and  the  IDL  definitions  were  included  in  the  section 
pertaining  to  the  other  construct.  For  example,  the  section  covering  operators 
(section  4.5)  does  not  contain  IDL  definitions  because  operators  in  DIANA  are 
represented  as  function  calls,  and  the  related  IDL  definitions  are  included  in 
the  section  on  subprogram  calls  (section  6.4). 
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Structure  Diana 
Root  compilation  Is 

--  Private  Type  Definitions 

Type  source_position; 
Type  comments; 

Type  symbo1_rep; 

Type  value; 

Type  operator; 

Type  number_rep; 


”  2.  Lexical  Elements 
--  Syntax  2.0 

has  no  equivalent  in  concrete  syntax 
void  =>  ; 


--  2.3  Identifiers,  2.4  Numeric  Literals,  2.6  String  Literals 

--  Syntax  2.3 

not  of  interest  for  Diana 


DEF  NAME  ::= 

■  def'name  => 

SOURCE  JAME  1  PREDEF_NAME; 

1x_symfep  :  symbo1_rep; 

S0URCE_NAME 

0BJECT_NAME  I  TYPE_NAME  I  UNIT_NAME  I  LABEL_NAME 

object_name  => 

sm_obj_type  :  TYPE_SPEC; 

UNIT_NAME  => 

sm_first  :  DEF_NAME; 

--  2.3  Pragmas 

--  Syntax  2. 8. A 
--  pragma  ::= 

pragma  identifier  [ (argument_association  {,  argument_association} ) ]; 


pragma  =>  as_used_name_id  :  used_name_id, 

as_general_assoc_s  :  general_assoc_s; 
--~seq  of  EXP  and/or  assoc 

genera l_assoc_s  =>  as_list  :  Seq  Of  GENERAL_ASS0C; 


—  Syntax  2.8.B 
--  argument_association  ::= 

[argument_identif ier  =>]  name 
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I  [arguinent_identifier  =>]  expression 


--  3.  Declarations  and  Types 


--  3.1  Declarations 

--  Syntax  3.1 
--  declaration 

ob ject_dec 1 arat ion 
I  type_dicl arat ion 
I  subprogratn_decl  arat  ion 
I  task_decl arat ion 
I  exception_declaration 
1  renaming_decl arat ion 


number_dec 1 arat ion 
subtype_dec 1 arat ion 
package_dec 1 arat i on 
generic_decl arat ion 
generic~instantiation 
deferred  constant  declaration 


DECL 

ID_0ECL 

ID_DECL  => 
I0_S_0ECL 

ID_S_0ECL  => 
EXP_DECL 

EXP  DECL  => 


IDJ_0ECL  I  ID_DECL; 

type_decl 
I  subtype_decl 
I  task_decl 
I  UNIT_DECL; 

as_source_name  :  SOURCE_NAME; 

EXP_DECL 
I  exciption__dec1 
I  deferred_constant_decl ; 

as_source_name_s  :  source_name_s; 

0BJECT_0ECL 
I  nuniber_decl ; 

as  exp  :  EXP; 


--  3.2  Objects  and  Named  Numbers 


--  Syntax  3. 2. A 
--  object  declaration  ::= 

identif ier_l ist  :  [constant]  subtype_indication  [:=  expression]; 

I  identifier'list  :  [constant]  constraTned_array_def inition  [:=  expression 


EXP  ::=  void; 

CONSTRAINED_DEF  ;:=  subtype_indication; 

OBJECT_DECL  constant_decl  I  variable_decl ; 

OBJECT_DECL  *>  as_type_def  :  TYPE_DEF; 

constant_decl  =>  ; 
variable  dec!  =>  ; 
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OBJECT_NAME  INIT_08JECT_NAME; 


INIT  OBJECT  NAME  VC  NAME; 

INIT~OBJECT~NAME  =>  sin~init_exp  :  EXP; 


VC_NAME  variable_id  I  constant_id; 

VC_NAME  »>  sm_renamis_obj  :  Boolean, 

sm'address  :  EXP;  --  EXP  or  void 


variable_id  =>  s(n_is_shdred  :  Boolean; 

constant  id  *>  sm  first  :  OEF  NAME; 


--  Syntax  3.2.B 
--  number_declaration  ::= 

identif ier_l ist  :  constant  :=  universal_static_expression; 
number_decl  =>  ; 

INIT_0BJECT_NAME  ::=  numDer_id; 
number  id  »>  ; 


--  Syntax  3.2.C 

"  identif1er_list  identifier  {,  identifier} 

source  name  s  =>  as  list  :  Seq  Of  S0URCE_NAME; 


--  3.3  Types  and  Subtypes 
—  3.3.1  Type  Declarations 

--  Syntax  3. 3.1. A 

--  type_declaration  ::=  ful l_type_declaration 

I  incomplete_type_decldration  I  pri vate_type_declaration 

--  ful l_type_declaration  ;:= 

type  identifier  [discriminant_part]  is  type_def i ni tion; 


type_decl  => 


as_dscrmt_decl_s  :  dscrmt_decl_s, 
as_type_def  :  TYPE_DEF; 


TYPE  NAME  ;:=  type_id; 

TYPE'NAME  =>  sm_type_spec  ;  TYPE_SPEC; 


type_id  => 


sm  first  :  DEF  NAME; 


--  Syntax  3.3. l.B 
--  type_def inition  ::= 
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enumerat ion_type_def init  Ion 
I  real_type_def inition 
I  recofd_type_def inition 
I  derived_type_def inition 


i nteger_type_def inition 
array_type_aef inition 
acces s_type_def inition 


TYPE_0EF  ::= 

CONSTRAINEO_DEF 

ARR_ACC_DER_DEF 

ARR_ACC_DER_DEF  => 
TYPE  SPEC  ;:= 


enumerat ion_def 
I  CONSTRAINED  OEF 
1  ARR_ACC_0ER"0EF 
1  record_def; 

integer_def 
I  f1oat_dif 
I  fixed^def; 

constrai ned_array_def 
I  unconstrained_array_def 
I  access_def 
I  derived_def; 

as_subtype_indication  :  subtype_indication; 

DERIVABLE  SPEC; 


DERIVABLE  SPEC  FULLJYPE  SPEC  I  PRIVATE  SPEC; 

OERIVABLE'SPEC  =>  sm_derived  :  TYPE_SPEC, 

sm~is_anonymous  :~Boolean; 

FULL_TYPE_SPEC  task_spec  I  NONJASK; 


NONJASK  ;:=  SCALAR  I  UNCONSTRAINED  I  CONSTRAINED; 

N0N~TASK  =>  sm_base_type  :TYP£_SPEC; 


SCALAR 
SCALAR  => 
SCALAR  => 


enumeration  I  integer  I  REAL; 
sm_range  :  RANGE; 
cd_imp1_size  :  Integer; 


REAL  ::=  float  I  fixed; 

REAL  =>  sm_accuracy  :  value; 


UNCONSTRAINED  ::=  UNCONSTRAINED_COMPOSITE  !  access; 
UNCONSTRAINED  =>  sm_si2e  :  EXP;  --  EXP  or  void 


UNCONSTRAINED  COMPOSITE  ;:=  array  I  record; 
UNCONSTRAINED^COMPOSITE  =>  sm_isj imited  :  Boolean, 

sm_is_packed  :  Boolean; 

CONSTRAINED  ::=  constrained_array 

1  constrained~record 
I  constrained_access; 

CONSTRAINED  =>  sm_depends_on_dscrmt  :  Boolean; 
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--  Syntax  3. 3. 2. A 

--  subtype  declaration  :;=  subtype  identifier  is  subtype_indication; 
subtype_deci  =>  as_subtype_indication  :  subtype_indication; 

TYPE_NAME  ::=  subtype_id; 

subtype_id  *>  ; 

--  Syntax  3.3.2.B 

“  subtype_indication  ::=  type_inark  [constraint] 

--  type_niark  type_nafne  1  subtype_name 

CONSTRAINT  void; 

C0NSTRAINED_DEF  =>  as_constraint  :  CONSTRAINT; 

subtype_indi cation  =>  as_name  :  NAME; 

--  Syntax  3,3.2.C 
—  constraint  ::= 

range  constraint  I  f loatin9_point_constraint  I  f ixed_ppint_constraint 
r-  I  index'constraint  i  discriminant_constraint 

CONSTRAINT  ::=  DISCRETE  RANGE 

I  real_constraint 

I  index_constraint 

I  dscrmt  constraint; 


--  3.4  Derived  Type  Definitions 
--  Syntax  3.4 

—  derived  type_def inition  ::=  new  subtype_indication 
derived  def  =>  ; 


—  3.5  Scalar  Types 
--  Syntax  3,5 

--  range_constraint  range  range 

--  range  ::=  range_attribute 

I  simple_expression  ..  simple__expression 


DISCRETE  RANGE 


RANGE 
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I  d1screte_subtype; 

RANGE  ::=  range  1  range_attribute  I  void; 

RANGE  =>  sm_type_spec  7  TYPE_SPEC; 

range  =>  asexpl  :  EXP, 

as_exp2  :  EXP; 

range_attribute  =>  as_name  :  NAME, 

as_used_name_id  :  used_name_id, 
as_exp  7  EXP7  --  EXP  of  void 


--  3.5.1  Enumeration  Types 

--  Syntax  3.5.1. A 
--  enumeration_type_def inition 

(enumerat ion_Titeral_specif ication  {,  enumeration_1 itera1_specif ication} 
enumeration_def  =>  as_enum_1 iteral  s  :  enum  literal  s; 
enum_literai_s  =>  as_list  :  Seq  Of  ENUM_LITERAL; 

enumeration  =>  sm_litera1_s  :  enum_l iteral_s; 

--  Syntax  3.5.1.B 

--  enumeration_l iteral_specif ication  ehumeration_1 iteral 
--  enumeration_1 i teral  identifier  1  character_l iteral 

OBJECT_NAME  ENUM_LITERAL; 

ENUM_LITERAL  ;:=  enumeration_id  I  character_id; 

ENUM_LITERAL  =>  sm_aos  :  Integer, 

sm_rep  :  Integer; 

enumeration_id  =>  ; 
character_id  =>  ; 

—  3.5.4  Integer  Types 
--  Syntax  3.5.4 

--  integer_type_def inition  ;:=  range_constraint 
integer_def  =>  ; 
integer  =>  ; 

--  3.5.6  Real  Types 
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—  Syntax  3.5.6 

--  real  type_def inition  ::= 

fToating_point_constraint  I  f 1xed_po1nt_constraint 


REAL_CONSTRAINT  ::=  f 1oat_constraint 

I  fixed  constraint; 


REAL_CONSTRAINT  =>  sni_type_spec  :  TYPE_SPEC; 


”  3.5.7  Floating  Point  Types 

--  Syntax  3.5.7 

--  f loating_point_constraint 

floating  accuracy_def inition  trange_constraint] 

—  floating  accuracy_def inition  ::=  digits  static_siinple_expression 


float_def  =>  ; 

REAL_CONSTRAINT  =>  as_exp  :  EXP, 

as_range  :  RANGE; 

f loat_constraint  =>  ; 
float  =>  ; 


--  3.5.9  Fixed  Point  Types 
--  Syntax  3.5.9 

--  f ixed_point_constraint  ::= 

fixed_accuracy_def inition  [range_constraint] 

--  fixed_accuracy_def inition  ::=  delta  static_sin)ple_expression 

fixed_def  =>  ; 

f ixed_constraint  =>  ; 

fixed  =>  cd_impl__small  :  value; 


--  3.6  Array  Types 

--  Syntax  3. 6. A 
—  array _type  definition  ::= 

unconstrained_array_def inition  I  constrained_array_def inition 

--  unconstrained_array_def inition 

array ( index_subtype_def inition  {,  index_subtype_def inition] )  of 
cotnponint_subtype_i  nd  i  ca  t  i  on 
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--  constrained_array_def inition 

array  index_constraint  of  component_subtype_indication 


constrained_array_def  =>  as_constraint  :  CONSTRAINT; 

index_constraint  =>  as_discrete_range_s  ;  discrete_range_s; 

discrete_range_s  =>  as_list  :  Seq  Of  DISCRETE_RANGE; 

unconstrained_array_def  =>  as_index_s  :  index_s; 

sca1ar_s  =>  as_1ist  :  Seq  Of  SCALAR; 

array  =>  sm_index_s  :  index_s, 

sm_comp_type  :  TYPE_SPEC; 

constrained_array  =>  sm_index_subtype_s  :  scalar_s; 


--  Syntax  3.6.B 

--  index_subtype_def inition  ::=  type_mark  range  <> 


index  =>  as_name  :  NAME, 

sm~type_spec  ;  TYPE_SPEC; 

index_s  =>  as_l1st  Seq  Of  index; 


--  Syntax  3.6.C 

--  index_constraint  ::=  (discrete_range  [,  discrete_range}) 

-*  discrete_range  ::=  discrete_subtype_indication  I  range 

discrete_subtype  =>  as_subtype_indication  :  subtype_indication; 


--  3.7  Record  Types 

—  Syntax  3. 7. A 

—  record_type_def inition 

record 

coniponent_l  ist 
end  record 


REP  void; 

record_def  *>  as_comp_1ist  :  comp_list; 

sm_discriminant_s  :  dscrrnt_decl_s, 
sm'comp  list  :  comp  list. 


record  => 
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Sfn_representation  :  REP;  --  REP  or  void 
constrained_record  =>  sm_normali2ed_dscnnt_s  :  exp_s; 


—  Syntax  3.7.B 

—  component_list  ;:= 

coinponent_declaration  {con)ponent_declaration} 

I  {coinponent_declarationi  variant_part 
I  null; 

—  component_declaration  :;= 

--  identif 1er_l ist  :  coniponent_subtype_def inition  [:=  expression]; 

--  coinponent_subtype_def inition  ::=  subtype_indication 


DECL  nun_comp_decl ; 

INIT  OBJECT  NAME  :: 

C0MP~NAME  :T= 

C0MP_NAME  => 

coinponent_id  =>  ; 

--  3.7.1  Discriminants 

--  Syntax  3.7.1 
--  discriminant_part  ::= 

(discrim1nant_specif ication  {;  discr1minant_specif ication}) 


=  C0MP_NAME ; 

component_id  I  discriminant_id; 
sm_comp_rep  ;  COMP_REP_ELEM; 


-  discriminant_specif ication 

identifier  list  :  type  mark  [:=  expression] 


ITEM 

DSCRMT_PARAM_DECL 
DSCRMT_PARAM_DECL  => 

dscrmt_decl_s  => 
dscrmt_decl  =>  ; 
discriminant  id  => 


OSCRMT_PARAM_DECL; 
dscrmt_decl ; 

as_source_name_s  :  source_name_s, 
as_name  :~NAME7 
as_exp  :  EXP; 

as_list  ;  Seq  Of  dscrmt_decl; 


sm  first  :  0EF_NAME; 


--  3.7.2  Discriminant  Constraints 
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--  Syntax  3.7.2 

discriminant_constraint 

(discriminant_association  {,  discrim1nant_association}) 

”  d1scriininant_association  ::  = 

[discriininant_sitnple_name  { Idi scriminant_simple_name}  =>]  expression 


dscnnt_constraint  =>  as_general_assoc_s  :  genera1_assoc_s; 


”  3.7.3  Variant  Parts 

—  Syntax  3. 7. 3, A 
--  variant_part  ::= 

case  discriminant_simp1e_nanie  is 
variant 
{variant} 
end  case; 

--  variant  ::= 

when  choice  (I  choice}  => 
component_1 ist 


VARIANT_PART  ::= 

variant_part  1  void; 

variant_part  => 

as_name  :  NAME, 
as~variant_s  :  variant_s; 

variant_s  => 

as_1ist  :  Seq  Of  VARIANTJLEM; 

VARIANT_ELEM  ::= 

variant  1  variant_pragnia; 

variant  => 

as_choice_s  :  choice_s, 
as_comp_1 ist  :  comp_1ist; 

choice_s  => 

as_list  :  Seq  Of  CHOICE; 

comp_list  => 

as_decl_5  :  dec1_s, 
as_variant_part  :  VARIANT_PART, 
as_pragtna_s  :  pragnia_s; 

variant_pragma  => 

as_pragma  :  pragma; 

—  Syntax  3.7.3.B 

--  choice  ::=  simple_expression 

I  d1screte_range  I  others  I  component_simp1e_name 


CHOICE  ::=  choice_exp  I  choice_range  I  choice_others; 

choice_exp  =>  as_exp  :  EXP; 
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cho1ce_range  =>  as_discrete_range  :  DISCRETE_RANGE; 

choice  others  =>  ; 


"  3.8  Access  Types 
--  Syntax  3.8 

—  access_type_def inition  access  subtype_indication 

access_def  =>  ; 

access  *>  stn_storage_si2e  :  EXP,  --  EXP  or  void 

sm~1s_contf oiled  :  Boolean, 
siii~desig_type  :  TYPE_SPEC, 
sm'master  :  ALL_0ECL; 

constrained_access  =>  sm_desig_tyoe  :  TYPE_SPEC; 


--  3.8.1  Incomplete  Type  Declarations 


--  Syntax  3.8.1 

--  incomplete_type_declaration  ::=  type  Identifier  [discriminant_part]; 


TYPE_DEF  ::= 
TYPEJPEC  = 
incomplete  => 
TYPE  SPEC  ::= 


void; 

incomplete; 

sm_discriminant_s  :  dscrmt_decl_s; 
void; 


--  3.9  Declarative  Parts 

—  Syntax  3. 9. A 

--  declarative_part  :;= 

{basic_declarative_item}  {iater_declarative_'’'teirl 

—  basic_declarative_item  ::=  basic_declaration 

1  fepresentation_clause  I  use'clause 

OECL  ;;=  REP; 

DECL  ::=  USE_PRAGMA; 

USE_PRAGMA  ;:=  use  I  pragma; 


--  Syntax  3.9.B 

--  1ater_declarati ve_item  ::=  body 

I  subprogram_declaration  I  package_declaration 
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1  task_(jec1aration  I  generic_declaration 

I  use_clause  1  generic'instantiation 

--  body  ::=  proper_body  I  stub 

—  proper_body  ::=  subprogram_body  I  package_body  1  task_body 

ITEM  DECL  I  SUBUNITJOOY; 

iteni_s  =>  as_1ist  :  Seq  Of  ITEM; 

UNIT  OECL  generic  ded 

1  NON_GENERIC_OECL; 

UNIT_DECL  =>  as_header  :  HEADER; 

NON_GENERIC_DECL  ::=  subprog_entry_decl 

1  package_dec1 ;~ 

NON_G£NERIC_D£CL  =>  as_unit_kind  :  UNIT_KIND; 


--  4.  Names  and  £xpressions 


--  4.1  Names 

--  Syntax  4.1. A 
--  name  simple_name 

I  character_Titera1  (  operator_symbol 

I  indexed_component  I  slice 

I  selected_component  I  attribute 

--  simp1e_name  ::=  identifier 

NAM£  ;:=  0£SIGNAT0R 

I  NAME_EXP; 

NAM£_EXP  NAME_VAL 

1  indexed 

I  slice 

I  all; 

NAME_£XP  =>  as_name  :  NAME; 

NAME_EXP  =>  sm~exp_type  ;  TYPE_SPEC; 

NAM£_\/AL  ::=  attribute 

I  selected; 

NAM£_VAL  =>  sm_value  :  value; 

DESIGNATOR  ::=  USE0_0BJECT  I  US£0_NAM£; 

DESIGNATOR  =>  sm_defn  :  DEF_NAME, 

lx_sytnrep  :  symbol_rep; 

used_op  I  used_name_id; 


USED  NAME  ::= 
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used_op  =>  ; 
used3name_id  *>  ; 

USED_OBJECT  used_char  I  used_object_id; 

USEO'OBJECT  =>  sm_exp_type  :  TYPE_SPEC7 

sm^value  :  value; 

used_char  *>  ; 
used7object_id  *>; 


”  Syntax  4.1.B 

—  prefix  name  I  function_call 

NAME^VAL  ::=  function_cal 1 ; 

--  4.1.1  Indexed  Components 
--  Syntax  4.1.1 

--  indexed_component  ::=  pref ix(expression  {,  expression}) 
exp_s  =>  as_1ist  :  Seq  Of  EXP; 

indexed  =>  as_exp_s  :  exp_s; 


--  4.1.2  Slices 
Syntax  4.1.2 

--  slice  pref ix(discrete_range) 

slice  =>  as_discrete_range  :  DISCRETE_RANGE; 


--  4.1.3  Selected  Components 
--  Syntax  4.1.3 

--  selected_component  pref ix. selector 

--  selector  simple_name 

I  character_l iteral  I  operator^symbol  I  all 

selected  =>  as_designator  :  DESIGNATOR; 

all  =>  ; 


--  4.1.4  Attributes 
--  Syntax  4.1.4 

--  attribute  ::=  pref ix ' attribute_designator 

--  attribute_designator  ::=  simple_name  [ (uni versa1_static_expression) ] 
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attribute  =>  as_used_name_id  :  used_naffle_id, 

as_exp  :  EXP; 


--  4.2  Literals 


—  4.3  Aggregates 

--  Syntax  4. 3. A 
--  aggregate  ::= 

(component_association  {,  component_association}) 

aggregate  *>  as_general_assoc_s  :  general_assoc_s; 

aggregate  =>  sm_normal i2ed_corop_s  :  generil_assoc_s; 


--  Syntax  4.3.B 
--  component_association  ::= 

Cchoici  (I  choice)  =>  ]  expression 


GENERAL_ASSOC  ::=  NAMED_ASSOC  1  EXP; 


NAMED  ASSOC  ::= 
NAMED^ASSOC  => 

named  => 

--  4.4  Expressions 


named; 

as_exp  :  EXP; 
as_choice  s  :  choice  s; 


--  Syntax  4. 4. A 
--  expression  ::= 

relation  {and  relation)  1  relation  {and  then  relation) 
I  relation  {or  relation)  j  relation  {or  else  relation) 

I  relation  {xor  relation) 


EXP_\/AL  ::=  short_circuit; 

short_circuit  =>  as_expl  :  EXP, 

as~short_circuit_op  :  SHORT_CIRCUIT_OP, 
as_exp2  T  EXP; 

SHORT_CIRCUIT_OP  ::=  and_then  I  or_else; 

and_then  =>  ; 
or  else  =>  ; 


--  Syntax  4.4.B 
--  relation  ::= 

simple_expression  [relational_operator  simple_expression] 
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I  s1(npie_expression  [not]  in  range 
I  simple_expression  [not]  in  type_mark 


EXP_VAL_EXP 

MEMBERSHIP  ::= 
MEMBERSHIP 


MEMBERSHIP; 

range_memDership 
as  membership_op 


type_membersnip; 
MEMBERSHIP  OP; 


range_inembership  =>  as_range  :  RANGE; 

type_inembership  =>  as_name  :  NAME; 

MEMBERSHIP_OP  ::=  in_op  I  notjn; 

in_op  =>  ; 
not  in  =>  ; 


--  Syntax  4.4.C 
--  simple_expression  ::= 

[unary _operator]  term  {binary _adding_operator  term] 

—  term  ::=  factor  {multip1ying_operator  factor] 

—  factor  :;=  primary  [  primary]  j  abs  primary  |  not  primary 


"  Syntax  4.4.D 
--  primary  ::= 

numeric_] iteral  I  null  I  aggregate  1  string_l iteral  I  name  I  allocator 
I  function_cal 1  I  type_conversion  I  qual if iecl_expression  I  (expression) 


EXP  ::= 

NAME 

1  EXPJXP; 

EXPJXP  ::  = 

EXP_VAL 

t  AGG  EXP 


I  qual if ied_al locator 
I  subtype_a1 locator; 


EXPJXP  => 

sm_exp_type  :  TYPE_SPEC; 

EXPJAL  ::  = 

numeric_l iteral 

1  null  access 

1  EXPJALJXP; 

EXPJAL  => 

sm_value  :  value; 

EXPJALJXP  ::  = 

QUALJONV 

1  parenthesized; 

EXPJALJXP  => 

as_exp  :  EXP; 

AGGJXP  ::  = 

aggregate 

1  string_literal ; 
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AGG_EXP  *>  sm_discrete_range  :  DISCRETE_RANGE; 

parenthesized  *>  ; 

nuraeric_l  iteral  =>  Ix_numrep  :  nuinber_rep; 

Str1ng_literal  =>  Ix_symrep  :  symbol_rep; 

null_access  »>  ; 

--  4.5  Operators  and  Expression  Evaluation 
--  Syntax  4.5 

--  logical_operator  ::=  and  I  or  I  xor 
--  relational_operator  ::=  =  1  /=  I  <  I  <=  I  >  I  >= 

--  adding_operator  ::=+]-!& 

--  unary _operator  ::=  +  1  - 

--  multiply ing_operatO'‘  ::=  *  I  /  I  mod  1  rem 

--  highest_precedence_operator  ::=  **  I  abs  I  not 

--  4.6  Type  Conversions 
--  Syntax  4.6 

--  type_conversion  ;:=  type_mark (expression) 

QLIAL_CONV  conversion 

I  qualified; 

QUAL_C0N\/  =>  as_name  :  NAME; 

conversion  =>; 

--  4.7  Qualified  Expressions 

--  Syntax  4.7 

--  qual if ied_expression 

type_mirk ' (expression)  I  type_mark 'aggregate 

qualified  =>  ; 

--  4.8  Allocators 

"  Syntax  4.8 
—  allocator  ::= 

new  subtype_ind1cation  I  new  qualified_expression 
qualified  allocator  =>  as_qualified  :  qualified; 
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subtype_anocator  =>  as_subtype_indication  :  subtype_indication, 

sm~desig_type  :  TYPE_SPEC; 


--  5.  Statements 

5.1  Simple  and  Compound  Statements  -  Sequences  of  Statements 
--  Syntax  5.1. A 

--  sequence_of_statements  ::=  statement  {statement} 


STM_ELEM  STM  I  stmpragma; 

stm_s  =>  as_1ist  :  Seq  Of  STM_ELEM; 


stm_pragma  => 


as_pragma  :  pragma; 


--  Syntax  5.1.B 
--  statement  ::= 

{label}  simple_statenient  I  {label}  compound_statement 


STM  labeled; 

labeled  =>  as_source_name_s  :  source_name_s, 

as'pragma^s  ;  pragma_s, 
as'stm  :  STM; 


--  Syntax  5.1.C 
--  simple_statement  ::=  null 
I  assignment_statement 
I  exit_statement 
I  goto_statement 
I  delay_statement 
I  raise  statement 


statement 

1  procedure_cal 1_statement 
I  return_5tatement 
I  entry_cal l_statement 
I  abort_statement 
i  code  statement 


STM  ::= 

STM 

STM_WITH_EXP 

STM_WITH_EXP  ::= 
STM_WITH_EXP  => 
STM  WITH  EXP  NAME 


nul l_stm 
I  abort; 

STM_WITH_EXP; 

return 
I  delay; 

STM_WITH_EXP_NAME; 
as_exp  ;  EXP; 
assign 
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I  exit 

I  code; 

STM_WITH_EXP_NAME  =>  as_natne  :  NAME; 

STM  :;=  STM_WITH_NAME ; 

STM  WITH  NAME  ::=  goto 

I  raise; 

STM  WITH  NAME  CALLJTM; 

CALL_STM~::=  entry _ca1l 

I  procedure_can ; 

STM_WITH_NAME  =>  as_name  :  NAME; 


--  Syntax  5.1.D 
--  compound_statement  ::= 

if_statement  I  case_statement 

I  loop_statement  I  block_statenient 

I  accept_statement  I  select_statement 

STM  accept 

I  BLOCK  LOOP 

I  ENTRY'STM; 

STM_WITH_EXP  case; 

STM  CLAUSESJTM; 

CLAUSES  STM  if 

I  se1ective_wait; 

CLAUSES_STM  =>  as_test_clause_elem_s  :  test_clause_elem_s, 

as  stm  s  :  stm  s; 


--  Syntax  S.i.E 

--  laoel  << ]abel_simp1e_narne>> 

LABEL_NAME  ::=  label_id; 

LABEL_NAME  =>  sm_stm  :  STM; 

label  id  =>  ; 


--  Syntax  5.1.F 
--  null_statenient  null  ; 

null  stm  =>  ; 


--  5.2  Assignment  Statement 
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--  Syntax  5.2 

--  assignment_statement  ::= 

variabli_name  :=  expression; 

assign  =>  ; 


—  5.3  If  Statements 

—  Syntax  5. 3. A 

—  if_statement  ::= 

1f  condition  then 

sequence_of_statements 
{elsif  conditTon'then 

sequence_of_statements} 

[else 

sequence_of_statements ] 
end  if; 

if  =>  ; 

TEST_CLAUSE  cond_clause; 

TEST  CLAUSE  =>  as_exp  :  EXP. 

as_stt!t_s  :  stm_s; 

cond  clause  =>  ; 


--  Syntax  5.3.B 

--  condition  ::=  boolean_expression 


--  5.4  Case  Statements 


--  Syntax  5.4 
--  case_statement  ::= 

case  expression  is 

case_statement_aUernati  ve 
{case_statement_aUerndt  i  ve} 


end  case; 


--  case  statement_a1ternative  ::= 
when  choice  {I  choice  }  => 
sequence_of_statements} 


ALTERNATIVEJLEM  ::  = 
case  => 

alternat1ve_s  => 
alternative  => 


alternative  I  alternati ve^pragma; 

as_alternative_s  :  alternative_s; 

as_list  :  Seq  Of  ALTERNATIVEJLEM; 

as_choice_s  :  choice_s, 
as  stm  s  T  stm  s; 
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alternative_pragma  =>  as_pragnia  :  pragma; 


--  5.5  Loop  Statements 

--  Syntax  5. 5. A 
--  loop_statement 

[Toop  simple_name: ] 

riteration_scheme]  loop 
sequence_of_statements 
end  loop  [ loop_simple_name]; 


BL0CI<_L00P  ::  = 

loop; 

BLOCK_LOOP  => 

as_source_name 

:  SOURCE_NAME; 

SOURCE_NAM£ 

void; 

LABEL_NAME  ::= 

block_loop_id; 

block_loop_id  =>  ; 

ITERATION  :;= 

void; 

loop  => 

as_iteration  : 
as~stm_s  :  stm_ 

ITERATION, 

.s; 

--  Syntax  5.5.B 

--  iteration_scheme  ;:=  while  condition 
I  for  loop_parameter_specif ication 

--  loop_parameter_specif ication 

identifier  in  [reverse]  discrete_range 


ITERATION  ;:=  F0R_REV; 

F0R_REV  ::=  for  I  reverse; 

F0R_RE\/  =>  ds_source_name  :  SOURCE_NAME, 

as_discrete_range  :  DISCRETE_RANGE ; 

for  =>  ; 
reverse  =>  ; 

08JECT_NAME  ::=  iteration_id; 

iteratTon_id  =>  ; 

ITERATION  ::=  while; 

while  =>  as_exp  ;  EXP; 


--  5.6  Block  Statements 


] 


i 

.  j 


DIANA  Reference  Manual  Draft  Revision  4 
IDL  SPECIFICATION 


--  Syntax  5.6 
--  block  statement 

tbTock_s1mp1e_name: ] 

[declare” 

declarative_part] 

begin 

sequence_of_statements 

[exception 

except ion_handler 
[exception”handler} ] 
end  [block_simple_name]; 
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BL0CK_L00P  :;=  block; 

block  =>  as_b1ock_body  :  block_body; 

block_body  =>  as_1tem_s  :  item_s, 

as'stms  :  stm_sT 
as  alternative  s  :  alternative_s; 


--  5.7  Exit  Statements 

—  Syntax  5.7 
--  exit_statement  ::= 

exit  [loop_name]  [when  condition]; 


NAME  void;, 

exit  =>  sm  stm  :  STM; 


--  5.8  Return  Statements 
--  Syntax  5.8 

--  return_statement  return  [expression]; 
return  =>  ; 

—  5.9  Goto  Statements 

—  Syntax  5.9 

--  goto_statement  ::=  goto  label_name; 
goto  =>  ; 


--  6.  Subprograms 

--  6.1  Subprogram  Declarations 
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—  Syntax  6.1. A 

--  subprogram_dec1aration  subprogram_spec1fication; 


subprog_entry_decl  => 

9 

UNIT_NAME 

NON_TASK_NAME; 

NON  TASK  NAME 

non“task~name  => 

SUBPR06_PACK_NAME; 
sm_spec~:  HEADER; 

SUBPROG  PACK  NAME 
SUBPROG"PACK~NAME  => 

SUBPROG_NAME; 
sm_unit~desc  :  UNIT_DESC, 
sm_address  :  EXP; 

SUBPROG  NAME 
SUBPROG_NAME  => 

procedure_id  1  function_id  1  operator_id; 
sm_is_inline  :  Boolean," 
sm^interface  :  PREDEF_NAME; 

UNIT  DESC  ::= 

1 

UNIT_KIN0  1  BODY 

implTcit_not_eq  1  derived_subprog; 

UNIT_KIND 

void; 

derived_subprog  => 

sm_derivable  :  SOURCE_NAME; 

implicit_not_eq  => 

sm_equal  :  SOURCE_NAME; 

procedure_fd  =>  ; 
function_Td  =>  ; 
operator”id  =>  ; 

--  Syntax  6.1.8 

--  subprQgram_specif ication  ::= 

procedure  identifier  [formal_part] 

I  function  designator  [ formal _part]  return  type_mark 

--  designator  :;=  identifier  1  operator_symbol 

--  operator_symbol  :;=  string_literal 


HEADER  ::= 

SUBP_ENTRY_HEADER  ::= 
SUBP_ENTRY_HEADER  => 


SUBP_ENTRY_HEADER; 
procedure_spec  I  function_spec; 
as_param_s  :  param_s; 


procedure_spec  =>  ; 


function_spec  =>  as_name  :  NAME; 


DIANA  Reference  Manual  Draft  Revision  4 
lOL  SPECIFICATION 


Page  2-25 


--  Syntax  6.1.C 
--  forma l_part  ::= 

(pafameter_specif ication  (;  parameter_specif icatlon}) 

--  parameter_specif ication 

identif ier_l ist  :  mode  type_mark  [:=  expression] 

--  mode  [in]  I  in  out  I  out 


param_s  => 


PARAM 
in  *> 

in_out  =>  ; 
out  =>  ; 

INIT_OBJ£CT_NAME 

PARAM  NAME  ::= 
PARAM"NAME  => 


as_list  :  Seq  Of  PARAM; 


OSCRMT  PARAM  OECL  PARAM; 


in  I  out  I  in_out; 
lx_default  :  Boolean; 


PARAM_NAME ; 

in  id  I  in_out_id  I  out_id; 
sm"first  :  OEF  NAME; 


in_id  »>  ; 
in”out_id  =>  ; 
oiJt_id~=>  ; 


--  6.3  Subprogram  Bodies 

—  Syntax  6.3 
--  subprogram_body  ::= 

subprogram_specif ication  is 
[declafative_part] 
begin 

sequence_of_statements 

[exception 

except ion_hand Ter 
{exception_handler} ] 
end  [designator]; 


body  ;:=  block_body  I  stub  I  void; 

subprogram_body  =>  as_header  :  HEADER; 


--  6.4  Subprogram  Calls 
—  Syntax  6.4 

--  procedure_ca1 l_statement  ::= 
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procedure_name  [actual_parameter_part]: 

--  function_can  = 

functTon_name  [actua1_parameter_part] 

--  actua1_parameter_part 

(pafameter_association  {,  paranieter_association}) 


--  parameter_association 

[formaT_parameter  =>]  actual_paranieter 

--  formal_parameter  parameter_simple_name 

--  actual _parameter 

expression  I  var iable_name  I  type_mark(variable_name) 


CALL  STM  => 

CALL  jTM  => 

procedure^call  => 

function_cal 1  => 
function^call  => 
function  call  »> 


as  general_assoc_s  :  general_assoc_s; 
sin~nornialized_pafam_s  :exp_s; 


as_general_assoc_s  :  general_assoc_s; 
sm_normali2ed_parain_s  ;  exp_s; 
lx_prefix  :  Boolean; 


NAMED_ASSOC  assoc; 


assoc  => 


as  used  name  :  USED  NAME; 


--  7.  Packages 

--  7.1  Package  Structure 

--  Syntax  7.1, A 

--  package_declaration  ::=  package_specif ication; 


package_dec1  =>  ; 

SUBPROG_PACK_NAME  package_id; 
package_id  =>  ; 


--  Syntax  7.1.B 
--  package_specif ication 

package  identifier  is 

{basic_declarative_item} 

[private 

{basic_declarative_item} ] 
end  [package  simple  name] 
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package  spec  =>  as_dec1_sl  :  dec1_s, 

as~dec1_s2  :  dec1~s; 

decl_s  »>  as_list  :  Seq  Of  OECL; 


—  Syntax  7.1.C 

—  package_body 

package  body  package_simple_name  is 
[declarative_partl 
[begin 

sequence_of_statements 

[exception 

except ion_hand Ter 
{exception^handler} }] 
end  [package_simple_natne]; 


package_body  => 


--  7.4  Private  Type  and  Deferred  Constant  Declarations 

—  Syntax  7. 4. A 
--  private_type_declaration 

type'identif ier  [discriminant^part]  is  [limited]  private; 


TYPE_DEF  •  private_def  I  l_private_def ; 

private_def  =>  ; 
l_private_def  =>  ; 

TYPE_NAME  ::=  pri vate_type_id  I  l_pri vate_type_id; 

pri vate_type_id  =>  ; 
l_private_type_id  =>  ; 

PRIVATE_SPEC  private  I  1_private; 

PRIVATE~SPEC  =>  stn_discriminant_s  :  dscrmt_decl_s, 

sm_type_spec  ;  TYPE_SPEC; 

private  =>  ; 
l_private  *>  ; 


--  Syntax  7.4.B 

--  deferred_constant_declaration 

identifier_list  :  constant  type_mark; 


deferred  constant  decl  =>  as  name  :  NAME; 
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--  8.  Visibility  Rules 

—  ^  «SSS3SXSSaS3SSSS33SSS 

--  8.4  Use  Clauses 
--  Syntax  8.4 

--  use_clause  use  package_name  {,  package_name} ; 
use  ■>  as_name  s  :  name  s; 


--  8.5  Renaming  Declarations 
--  Syntax  8.5 

--  renaming_declaration  ::= 

identifier  :  type_mark 
I  identifier  :  exception 
I  package  identifier 
I  subprogram_specif ication 


renames  object_name; 
renames  except ion_name; 
renames  package_name; 
renames  subprogram_or_entry_name ; 


ID_DECL 

SIMPLE_RENAME  DECL  ::= 

I 

SIMPLE_RENAME_OECL  *> 

renames_obj_decl  => 

renames_exc_decl  =>  ; 

UNIT_KIND  ::= 

RENAME_INSTANT  ::= 
RENAME_INSTANT  => 

renames  unit  =>  ; 


SIMPL£_R£NAME_OECL; 

renames_obj_decl 
renames_exc~decl ; 

as_name  :  NAME; 

as_type_mark_name  :  NAME 

RENAME_INSTANT; 

renames_unit; 
as  name  :  NAME; 


--  9.  Tasks 

--  9.1  Task  Specifications  and  Task  Bodies 

—  Syntax  9.1. A 

--  task_declaration  ::=  task_specif ication; 

—  task_specif ication 

task  [type]  identifier  [is 
{entry_declaration} 

{ representat i on_c 1 ause } 
end  [task  simple  name]] 
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task_dec1  »>  as_decl_s  :  dec1_s; 

task_spec  »>  sm_decl_s  :  decl_s, 

sm'body  :  BODY, 

sm_address  :  EXP, 
sm_size  :  EXP, 
sm~storage_si2e  :  EXP; 


--  Syntax  9.1.B 
--  task_body  ::= 

task  body  task_s1n'p1e  name  is 
[declarative_partT 

begin 

sequence_of_statements 

[exception 

exception_handler 
{exception_handier} ] 
end  [task_simple_name]; 


task_body  =>  ; 

UNIT_NAME  task_body_1d; 

task_body_id  =>  sm_type_spec  :  TYPE_SPEC, 

sm~body~:  BODY; 

9.4  Task  Dependence  -  Termination  of  Tasks 
ALL_DECL  ::=  block_master; 

block  master  =>  sm_stm  :  STM; 


--  9.5  Entries,  Entry  Calls  and  Accept  Statements 

--  Syntax  9. 5. A 
--  entry_declaration  ::= 

entry  identifier  [ (discrete_range) ]  [formal_part ] ; 


SUBP_ENTRY_HEAOER 
entry  => 
SOURCE_NAME  :;= 
entry_id  => 


entry; 

as_discrete_range  :  DISCRETE_RANGE; 

entry_id; 

sm_spec  :  HEADER, 
sm~address  :  EXP; 


Syntax  9.5.B 
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--  entry_cal l__statement  ::=  entry_name  [actual_parameter_part]; 
entry _can  »>  ; 


”  Syntax  9.5.C 
"  accept_statement  ::= 

accept  entry_simple_name  [ (entry_index) ]  tfonnal_part]  [do 
sequence_of_statements 
end  Centry_simple_name]]; 

—  entry_index  ::=  expression 

accept  *>  as_name  :  NAME, 

as_param_s  :  paratn_s, 
as^stm  s~:  stm  s; 


--  9.6  Delay  Statements,  Duration  and  Time 
'■  Syntax  9.6 

--  delay __statement  delay  simple_expression; 

delay  =>  ; 


--  9.7  Select  Statements 
--  Syntax  9.7 

"  select_statement  select ive_wa it 

I  conditional_entry_cal.l  I  timed_entry_cal  1 


--  9.7.1  Selective  Waits 


--  Syntax  9, 7.1. A 
--  selecti ve_wait  ::= 
select 

select_alternative 

{or 

select_alternative} 

[else 

sequence_of_statements ] 
end  select; 


selective  wait  =>  ; 


"  Syntax  9.7. l.B 
--  selective_alternative  ;:= 

[when  condition  =>] 

selective  wait  alternative 
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--  se1ective_wait_aUernati ve  ::=  accept_a1ternative 
I  delay_alternat1ve  I  tenii1nate_alternative 

--  accept_alternative  accept_statement  [sequence_of_statements] 

--  delay _aUernative  ::=  delay_statement  [sequence_of_statements] 

--  tenninate_alternative  ::=  terminate; 

TEST_CLAUSE_ELEM  :;=  TEST_CLAUS£  I  se1ect_alt_pragma; 
TEST_CLAUSE  ::=  se1ect_a1ternati ve; 

test_clause_elem_s  =>  as_list  :  Seq  Of  TEST_CLAUSE_ELEM; 
se1ect_alternative  =>  ; 
se1ect_aU_pragma  =>  as_praqma  :  pragma; 

STM  ::=  terminate; 

terminate  =>  ; 


--  9.7.2  Conditional  Entry  Calls 
--  Syntax  9.7.2 

--  conditional_entry_cal 1  ;:= 
select 

entry _cal l_statement 
L sequence_of_statements  ] 

else 

sequence_of_statements 
end  select; 


£NTRY_STM  ;:=  cond_entry  1  timed_entry; 

ENTRY_STM  =>  as_stm_sl  :  stm_s,~ 

as_stm_s2  :  stm_s; 

cond_entry  =>  ; 


--  9.7,3  Timed  Entry  Calls 

--  Syntax  9.7.3 
--  timed_entry_call  ::= 
select 

entry_cal l_statement 
[sequence_of_s‘ 'tementsl 
or 

delay_alternative 
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end  select; 

timed_entry  *>  ; 

--  9.10  Abort  Statements 
--  Syntax  9.10 

—  abort_statement  abort  task_naffle  {,  task_name}; 

naroe_s  =>  as_list  :  Seq  Of  NAME; 

abort  »>  as_name_s  :  name_s; 

--  10.  Program  Structure  and  Compilation  Issues 
--  10.1  Compilation  Units  -  Library  Units 
--  Syntax  10.1. A 

--  compilation  {compilation_unit} 

compilation  =>  as_compltn_unit_s  :  compltn_unit_s; 

compltn_unit_s  =>  as_list  :  Seq  Of  compi lation_unit; 

--  Syntax  10.1.8 
--  compi lation_uni t  = 

context_clause  library_unit  I  context_clause  secondary _unit 
--  library _unit  ::= 

subprogram_declaration|  package_declaration 
!  generic_declaration  I  generic_instantiation 
t  subprogram_body 

--  secondary _un it  1 ibrary_unit_body  t  subunit 

--  1 ibrary_unit_body  ::=  subprogram_body  1  package_body 

ALL_DECL  void; 

pragma_s  =>  as_list  :  Seq  Of  pragma; 

compilation  unit  =>  as  context_elem  s  :  context_elem  s, 

as>1l_dec1  :  ALL_DECL, 

as_pragma_s  :  pragma_s; 


CONTEXT  ELEM 


context_pragma; 
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context_pragma  =>  '  as_prag!na  :  pragma; 

"  Context  Clauses  -  With  Clauses 
--  Syntax  10. 1.1. A 

—  context_clause  {with_clause  {use_clausel } 
context_elem_s  »>  ds_list  :  Seq  Of  CONTEXT_ELEM; 

—  Syntax  10. 1.1. B 

--  with_clause  with  unit_simple_name  {,  unit_simple_name}; 


CONTEXTJLEM  ::=« 
with  => 

use_pragma_s  => 


with; 

as_name_s  :  name_s, 
as~use_pragma_s  :  use_pragma_s; 

as_list  :  Seq  Of  USE_PRAGMA; 


--  10.2  Subunits  of  Compilation  Units 

—  Syntax  10. 2. A 
--  subunit  :;= 

separate  (parent_unit_naine)  proper_body 


subunit  => 

SUBUNIT  BOOT  ::= 
SUBUNIT^BODY  => 


as_name  :  NAME, 

as~subunit_body  :  SUBUNIT_BODY; 

subprogram_body  I  package_body  I  task_body; 
as_source_name  :  SOURCE_NAME, 
as_body  :  BODY; 


--  Syntax  10. 2. B 
--  body_stub  ::= 

~subprogram_specif ication  is  separate; 

I  package  body  package_simple_name  is  separate; 
I  task  body  task_siinpli_name  is  separate; 


stub  =>  ; 


--  11.  Exceptions 

--  11.1  Exception  Declarations 

--  Syntax  11.1 

--  exception_declaration  ::=  identifier^list  :  exception; 
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exception_decl  »>  ; 

SOURCE_NAME  except ion_id; 

except1on_id  =>  sm_renames_exc  :  NAME; 


--  11.2  Exception  Handlers 

--  Syntax  11.2 
--  except ion_hand1er  ::= 

when  except ion_cho ice  it  exception_choice}  => 
sequence_of_statements 

exception_choice  except ion_naine  1  others 


--  11.3  Raise  Statements 
--  Syntax  11.3 

--  raise_statement  ::=  raise  [ except i on_name ] ; 
raise  =>  ; 


--  12.  Generic  Program  Units 


--  12.1  Generic  Declarations 
--  Syntax  12.1. A 

—  generic  declaration  ::=  generic_specif ication; 

--  generic_specif ication  ::= 

generic  formal_part  subprogram_specif ication 
I  generic~formal~part  package_specif ication 


HEADER  ::=  package_soec; 

generic  decl  as_iteni_s  ’  item_s; 

NON_TASK_NAME  ::=  generic_id; 

generic  id  ->  sm  generic_param_s  z  item_St 

~  sm~body  :  BODY, 

sm  is  inline  :  Boolean; 


--  Syntax  12.1.B 

--  generic_formal_part  generic  {generic_parameter_declarationl 
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--  Syntax  12.1.C 

--  generii:_parameter_dec1aration  ::  = 

Identif 1er_lTst  :  [in  [out]]  type_mark  [:*  expression] 
I  type  identTfier  is  gener1c_type_dif inition; 

I  private_type_declaration 
I  with  subprogfatn_specif ication  [is  name]; 

I  with  subprogram^pecif ication  [is  <>]; 


UNIT_KIND  GENERIC_PARAM; 

6ENERIC_PARAM  name_defauU 

I  box_default 

I  no_default; 

name_default  =>  as_name  :  NAME; 

box_default  =>  ; 
no  default  =>  ; 


Syntax  12.1.0 

--  generic_type_def inition  ::= 

(<>)  I  range  <>  I  digits  <>  I  delta  <> 

I  array_type_def ini tion  I  access_type_def inition 


TYPE  OEF  :;=  formal_dscrt_def 

I  forma l~integer_def 
I  formal'f ixed_dif 
I  formal_float~def ; 

formal_dscrt_def  =>  ; 
formal'f ixed^def  =>  ; 
formal'f loat_def  =>  ; 
formal~integer_def  =>  ; 


--  12.3  Generic  Instantiation 

--  Syntax  12. 3. A 
--  generic_instantiation  ::= 
package  identifier  is 

new  generic_package_name  [generic_actua1_part]; 

1  procedure  identifier  is 

new  generic_procedure_name  [generic_actual_part] 
I  function  identifier  is 

new  generic_function_name  [generic_actual_part]; 

--  generic_actual_part 

(generic_association  {,  generic_association) ) 
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RENAME_INSTANT  ::=  instantiation; 

instantiation  =>  as_genera1_assoc_s  :  genera1_assoc_s; 

Instantiation  »>  sm  decl  s  :  decl~s; 


"  Syntax  12. 3. B 
”  generic_association  ;:= 

[geniric_formal_paranieter  =>]  generic_actual_parameter 
--  generic_fonnal_parameter  ::=  paraineter_siniple_nanie  I  operator_symbo1 


--  Syntax  12. 3. C 

—  generic_actual_parameter  expression  |  variable_naine 
I  subprogram_naine  I  entry_name  I  type_inark 


—  13.  Representation  Clauses  and 


--  Implementation  Dependent  Features 


—  13.1  Representation  Clauses 

--  Syntax  13.1 

—  representation_clause 

type_reprisentation_clause  I  address_clause 

--  type_representation_clause  length^clause 

(“enumeration_representation_clause  (  record_representation_clause 


REP 

REP  => 


NAMED_REP  I  record_rep; 
as_name  :  NAME; 


NAMED  REP  => 


as_exp  :  EXP; 


--  13.2  Length  Clause 

--  13.3  Enumeration  Representation  Clauses 
"  Syntax  13.2 

—  length_clause  for  attribute  use  simple_expression; 
--  Syntax  13.3 

--  enumeration_representat1on_clause  ::= 

for  type_simple_name  use  aggregate; 


NAMED_REP  ::=  length_enum_rep; 

length_enum_rep  =>  ; 


--  13.4  Record  Representation  Clauses 
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--  Syntax  13. 4. A 

--  record_representat1on_clause 
--  for~type_simple_naine  use 

record  [alTgnment_c1ause] 

{ component_c 1 au se } 
end  record; 

--  a11gnment_clause  at  mod  static_simp1e_express1on; 


ALIGNMENT_CLAUSE  alignment  I  void; 

alignment  =>  as_pragma_s  :  pragma_s, 

as~exp  :  EXP; 

record  rep  =■>  as_a1ignment_clause  :  ALIGNMENT_CLAUSE, 

as_comp_rep_s  :  comp_rep_s; 


—  Syntax  13. 4. B 
--  component_c1ause  ::= 

component  simple  name  at  static_simple_expression  range  static_range; 


COMP  REP  ELEM 
COMPARE P^E LEM 

comp_rep_s 

comp_rep  => 

comp_rep_pragma  => 


comp_rep  I  void; 
comp~rep_pragma; 

as_list  :  Seq  Of  COMP_REP_ELEM; 

as_name  :  NAME, 
as~exp  :  EXP, 
as^range  :  RANGE; 

as_pragma  :  pragma; 


--  13.5  Address  Clauses 
--  Syntax  13.5 

--  address  clause  for  simple_name  use  at  simple_expression; 

NAME0_REP  :;=  address; 

address  =>  ; 


--  13.8  Machine  Code  Insertions 

—  Syntax  13.8 

—  code_statement  type_mark'record_aggregate; 
code  =>  ; 
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--  14.0  Input-Output 

sssssssxssssssass 

--  I/O  procedure  calls  are  not  specially  handled.  They  are 
--  represented  by  procedure  or  function  calls  (see  6.4). 


--  Predefined  Diana  Environment 


PREOEF  NAME 


attribute_id 
I  pragma_id~ 

I  argument_id 
I  bltn_opefator_id 
I  void; 


attribute_id  =>  ; 

TYPE_SPEC  un1versal_integer  I  universa1_f ixed  I  universal_real ; 

universal_integer  =>  ; 
universal'f ixed  =>  ; 
uni versal'real  =>  ; 


argument_id  =>  ; 
bltn_operator_id  => 
pragma_id  => 
argument_id_s  => 
ALLJOURCE  ;:  = 


sm_operator  :  operator; 

sm_argument_id_s  :  argument_id_s; 

as_ltst  :  Seq  Of  argument_id; 

OEF  NAME  I  ALL  DECL  I  TYP'’  DEF  1  SEQUENCES 
STMjLEM  I  general  ASSOC  TCONSTRAINT  |  CHOICE 
HEADER  I  UNIT  DESC”l  TEST  CLAUSE  ELEM 
M£MBERSHIP_OP~l  SHORT  CIRCUIT_OP"l  ITERATION 
ALTERNATIVE_ELEM  |  COMP  REPJLEM  1  CONTEX"  ELEM 
VARIANTJLEM  I  ALIGNMENT'CLAUSE  I  VARIANT_PART 
comp_list  1  compilation  T  compilation  unit  1  index; 


SEQUENCES  ::= 


ALLJOURCE  => 


alternative_s  i  argument_id_s  I  choice_s 
comp_rep_s  ~l  compltn_unit_s  I  context_eleiii_s 
decl_s  I  dscrmt_decl_s  I  gineral_assoc_s 
discrete  range_s  I  enum_literal_s  I  exp_s  I  item_s 
indexes  T  name  s  I  param_s  1  pragma_s  |~scalar_s~ 
source_name_s  T  stm_s  I  test_clause_elem  s 
use_pragffla_s  I  variant_s; 

lx_srcpos  ;  sour ce_posit ion, 
lx  consnents  ;  comments; 


ALLJECL 


ITEM  I  subunit; 


End 


CHAPTER  3 


SEMANTIC  SPECIFICATION 
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This  chapter  describes  the  semantics  of  DIANA.  The  structure  of  this 
chapter  parallels  the  DIANA  class  hierarchy.  Each  section  corresponds  to  a 
class  In  the  DIANA  class  hierarchy,  and  each  subsection  corresponds  to  a 
subclass  of  that  class  in  the  hierarchy.  Each  node  is  discussed  in  the  section 
corresponding  to  the  class  which  directly  contains  it. 

Since  the  class  structure  of  DIANA  is  a  hierarchy,  it  was  possible  to 

construct  hierarchy  diagrams  to  illustrate  pictorially  the  relationships  between 
the  various  nodes  and  classes.  At  the  end  of  each  major  section  is  a  hierarchy 
diagram  which  depicts  the  nodes  and  classes  discussed  in  that  section,  along 
with  the  attributes  which  are  defined  for  those  nodes  and  classes.  Beneath  each 
class  or  node  name  is  a  list  of  attribute  names  corresponding  to  the  attributes 

which  are  defined  at  that  level.  Hence  an  attribute  appearing  immediately  below 

a  class  name  is  defined  for  all  classes  and  nodes  which  are  below  that  class  in 
the  diagram. 

It  should  be  noted  that  the  classes  ALL_SOURCE  and  SEQUENCES  have  been 

omitted  from  this  chapter  due  to  the  simple  nature  of  their  structure  and  the 

fact  that  they  represent  optional  features  of  DIANA.  All  nodes  which  may 

represent  source  text  have  the  attributes  lx  srcpos  and  lx  comments;  however, 
DIANA  does  not  require  that  these  attributes  be  represented  in  a  DIANA 
structure.  The  sole  purpose  of  class  ALL_SOURCE  is  to  define  these  two 
attributes  for  its  constituents;  the  only  nodes  which  do  not  inherit  these 

attributes  are  those  belonging  to  class  TYPE_SPEC.  In  order  to  be  consistent, 

the  lOL  specification  of  DIANA  defines  a  sequence  node  (or  header)  for  each 
sequence;  however,  an  implementation  is  not  required  to  represent  the  sequence 

node  itself.  Class  SEQUENCES  is  a  set  of  sequence  nodes,  all  of.  which  have  a 

single  attribute  (other  than  lx  srcpos  and  lx  comments)  called  as  list  which 
denotes  the  actual  sequence. 

The  follo.ving  conventions  are  observed  throughout  this  chapter: 

(a)  All  attributes  which  are  inherited  by  the  node  void  are  undefined.  In 
addition,  no  operations  are  defined  for  the  attributes  inherited  by  the 
node  void. 

(b)  Although  a  class  may  contain  the  node  void,  an  attribute  which  has  that 

class  as  its  type  cannot  be  void  unless  the  semantic  specification 

explicitly  states  that  the  attribute  may  be  void. 

(c)  The  attributes  lx  srcpos  and  lx  comments  are  undefined  for  any  nodes 
which  do  not  represent  source  code.  For  certain  nodes,  such  as  those 
in  class  PREDEF_NAME,  these  attributes  will  never  be  defined. 

(d)  Unless  otherwise  specified,  all  nodes  represent  source  code. 

(e)  A  sequence  cannot  be  empty  unless  the  semantic  specification  explicitly 
allows  it. 

(f)  If  the  manual  specifies  that  the  copying  of  a  node  is  optional,  and  an 
implementation  chooses  to  copy  that  node,  then  the  copying  of  any  nodes 
denoted  by  structural  attributes  of  the  copied  node  is  also  optional. 


Section  3.1 


ALL  DECL 


3.1  ALL_OECL 

The  four  immediate  offspring  of  class  ALL  OECL  are  void,  subunit, 
b1oci(_Mster,  and  ITEM. 

The  subunit  node  represents  a  subunit,  and  has  two  non-lexical  attributes 
--  as  name  and  as  subunit  body.  The  attribute  as  name  denotes  the  name  of  the 
parefit"  uriTt  (a  selected,  used_naiiie_id,  or  useB_op  node);  as  subunit  body 
designates  the  node  correspond ing“to  the  proper  body? 

The  block_master  node  represents  a  block  statement  that  may  be  a  master 
because  it  contains  immediately  within  its  declarative  part  the  definition  of  an 
access  type  which  designates  a  task.  Its  only  non-lexical  attribute,  sm  stm, 
denotes  a  b1ock_body  node.  The  b1ock_iiiaster  node  can  only  be  referenced  by  the 
sm  master  attribute  of  the  access  node7  thereby  serving  as  an  intermediate  node 
between  the  access  type  definition  and  the  block  statement.  The  block  piaster 
node  does  not  represent  source  code. 


3.1.1  ITEM 

In  general,  the  nodes  in  class  ITEM  correspond  to  explicit  declarations; 
i.e.  declarative  items  that  can  be  found  in  formal  parts,  declarative  parts, 
component  lists,  and  program  unit  specifications.  Certain  declarative  nodes 
(subtype_decl ,  constant_decl ,  renaines_obj_decl ,  and  subprog  entry _decl)  may  also 
appear  in  another  context  --  as  a  part  of~a  sequence  of  declarations  constructed 
for  the  instantiation  of  a  generic  unit.  When  used  in  this  special  context 
these  declarative  nodes  are  not  accessible  through  structural  attributes,  and  do 
not  correspond  to  source  code. 

Certain  implicit  declarations  described  in  the  Ada  manual  are  not 
represented  in  DIANA:  the  predefined  operations  associated  with  type 
definitions;  label,  loop,  and  block  names;  anonymous  base  types  created  by  a 
constrained  array  or  scalar  type  definition;  anonymous  task  types;  derived 
subprograms.  Although  the  entities  themselves  have  explicit  representations 
(i.e.  defining  occurrences),  their  declarations  do  not. 

With  the  exception  of  the  node  nun_co«v_<lecl  and  the  nodes  in  classes  REP 
and  USE_PRAGMA,  all  of  the  nodes  in  class~ITEM  have  a  child  representing  the 
identif iir(s)  or  symbol (s)  used  to  name  the  newly  defined  entity  (or  entities). 
These  nodes,  members  of  class  SOURCE_NAME,  are  termed  the  "defining  occurrence" 
of  their  respective  identifiers;  they  carry  all  of  the  information  that 
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describes  the  associated  entity. 

The  classes  DSCRKT_^PARAM_DECL,  SUBUHIT_BODY,  and  DECL  comprise  ITEM. 


3 . 1 . 1 . 1  DSCRMT_PARAM_0£CL 

The  DSCRMT_PARAM_DECL  class  is  composed  of  nodes  representing  either  a 
discriminant  specification  or  a  formal  parameter  specification.  The  as  name 
attribute  defined  on  this  class  denotes  a  selected  or  used_na»e_i3~  node 
corresponding  to  the  type  mark  given  in  the  specification. 

The  dscnit_dec  node  represents  a  discriminant  specification.  The 
as  source  name  s~attribute  denotes  a  sequence  of  dscnit__id  nodes,  and  the  as  exp 
attribute  references  a  node  corresponding  to  the  default  initial  value;  if  there 
is  no  initial  value  given,  as  exp  is  void. 


3. 1.1. 1.1  PARAM 

A  node  in  class  PARAM  may  represent  either  a  formal  parameter  specification 
contained  in  a  formal  part,  or  a  generic  formal  object  declaration.  The 
as  source  name  s  attribute  denotes  a  sequence  of  in  id,  in_out_id,  and  outbid 
nodes,  unless  the  PARAM  node  corresponds  to  a  generic  formal  object  declaration, 
in  which  case  only  1n_id  and  in_out_id  nodes  are  permitted. 

The  in  node  represents  a  formal  parameter  declaration  of  mode  in.  Its 
as  exp  attribute  denotes  the  default  value  of  the  parameter,  and  is  void  if  none 
TT'gTven.  The  in  node  also  has  an  lx  default  attribute  which  indicates  whether 
or  not  the  mode  is  specified  explicitly. 

The  in_out  and  out  nodes  represent  formal  parameter  declarations  of  mode  in 
out  and  outT  respectively.  The  as  exp  attribute  of  these  nodes  is  always  void. 


3. 1.1.2  SUBUNITJOOY 

The  class  SUBUNIT_BOOY  is  composed  of  nodes  representing  declarations  of 
subunit  bodies.  The  as  body  attribute  defined  on  this  class  may  denote  either  a 
block^body  or  a  stub  node,  depending  on  whether  the  declaration  corresponds  to  a 
proper  body  or  a  body  stub. 

The  subprogram__body  node  represents  the  declaration  of  a  subprogram  body. 
The  as  source  name"  attribute  denotes  a  node  in  class  SUBPROG_NAME ,  and  the 
as  header  attribute  references  a  procedure_spec  or  a  function_spec~node. 

The  package_body  node  represents  the  declaration  of  a  package  body;  its 
as  source  name  attribute  refers  to  a  package_id  node.  If  the  package  body  is 
empty  (i.e.  Tt  contains  no  declarative  part,  no  sequence  of  statements,  and  no 
exception  handlers)  then  as  body  still  denotes  a  block_body  node;  however,  all 
of  the  sequences  in  the  block  body  node  are  empty. 
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The  task_bod>  node  represents  the  declaration  of  a  task  body;  its 
as  source  naiiie~attribute  denotes  a  task_body_1d. 


3. 1.1.3  OECL 

The  class  OECL  contains  the  nodes  associated  with  basic  declarative  items, 
record  component  declarations,  and  entry  declarations. 

The  node  null  coaq)_decl  represents  a  record  component  list  defined  by  the 
word  ‘‘null".  It  Ras  no  attributes  other  than  lexical  ones,  and  appears  only  as 
the  first  member  of  a  sequence  denoted  by  the  as_decl_s  attribute  of  a  coiiip__list 
node;  the  only  kind  of  node  which  can  succeed  it  Tn  the  sequence  is  a  pragma 
node. 


3. 1.1. 3.1  USE_PRAGMA 

The  class  USE_PRA6MA  contains  the  nodes  pragma  and  use. 

The  pragma  node  represents  a  pragma.  The  as_used_name_id  attribute  denotes 
the  name  of  the  pragma,  and  the  as_general  assoc_s  attribute  references  a 
possibly  empty  sequence  of  argument  associations  "(the  sequence  may  contain  a 
mixture  of  assoc  and  EXP  nodes). 

The  use  node  represents  a  use  clause.  The  as  name  s  attribute  represents 
the  list  of  package  names  given  in  the  use  clause.  If  the  use  clause  appears  as 
a  basic  declarative  item,  the  sequence  can  contain  both  used_name_id  and 
selected  nodes;  if  it  is  a  part  of  a  context  clause,  it  “will’contain 
used  name  id  nodes  only. 


3.1. 1.3.2  REP 

The  nodes  in  class  REP  correspond  to  representation  clauses  which  may 
appear  as  declarative  items  (i.e.  address  clauses,  length  clauses,  record 
representation  clauses,  and  enumeration  representation  clauses). 

The  node  record_rep  represents  a  record  representation  clause.  The 
attribute  as  name  references  a  used_name__1d  corresponding  to  the  record  type 
name;  as  alignment  clause  and  as  comp  rip  s  "denote  the  alignment  clause  and 
component  clauses^  respectively.  The  attribute  as  alignment  clause  is  void  if 
the  representation  clause  does  not  contain  an  alignment  clause,  and 
as  comp  rep  s  may  be  empty  if  no  component  clauses  or  pragmas  are  present. 


3.1. 1.3.2. 1  NAMED_REP 

The  nodes  length_enum_rep  and  address  comprise  the  class  NAMED_RtP,  a  group 
of  representation  clauses  which  consist  of  a  name  and  an  expression? 
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The  1ength_enum_rep  node  may  represent  either  a  length  clause  or  an 
enumeration  representation  clause.  In  the  former  case  the  as  name  attribute 
denotes  an  attribute  node  and  the  as  exp  attribute  corresponds  to  the  simple 
expression.  In  the  case  of  an  enumeration  representation  clause  the  as  name 
attribute  denotes  a  used_na»e_id  corresponding  to  the  enumeration  type,  and 
as  exp  references  an  aggregate  node. 

The  address  node  represents  an  address  clause.  Its  as  name  attribute 
references  a  node  from  the  class  USED_SOURCE_NAME  corresponding  to  the  name  of 
the  entity  for  which  the  address  is  being  specified.  The  as  exp  attribute 
records  the  address  expression. 


3. 1.1. 3. 3  ID_0ECL 

The  ID_0ECL  class  represents  those  declarations  which  define  a  single 
entity  ratKer  than  a  sequence  of  entities  (i.e.  declarations  defining  an 
identifier,  not  an  identifier  list).  Included  in  this  class  are  the  type  ded, 
subtype  decl,  and  task  decl  nodes,  as  well  as  the  UNIT  OECl  and 
simple_Rename_decl  classes,  representing  unit  declarations  and  ~  renaming 
declarations,~respecti vely . 

The  type_decl  node  represents  a  type  declaration  --  incomplete,  private, 
generic,  derived,  or  full.  The  only  type  declaration  that  is  not  represented  by 
this  node  is  that  of  a  task  type,  which  is  denoted  by  a  task_decl  node  instead. 
The  type  decl  node  has  three  non- lexical  attributes:  as  source  name, 
as  dscrmt  Heel  s.  and  as  type  def. 

The  as  source  name  attribute  of  a  type_decl  node  denotes  a  node 
representing  a  new  defining  occurrence  of  the  type  name,  the  kind  of  node 
depending  on  the  kind  of  type  declaration.  Certain  type  names  will  have  more 
than  one  declaration  point  --  those  corresponding  to  incomplete  types  or 
(limited)  private  types.  The  as  source  name  attribute  of  the  type_decl  node 
associated  with  a  (limitedT  private  type  declaration  references  a 
private_type_id  or  l_private_type_id  node;  for  all  other  type  declarations 
as  source  name  will”  designate  a  type_id  node.  The  subsequent  full  type 
declaration  for  an  incomplete  or  (limited)  private  type  is  treated  as  an 
ordinary  full  type  declaration;  hence  the  as  source  name  attribute  of  the  full 
type  declaration  corresponding  to  a  (limited)  private  type  will  denote  a  type_id 
rather  than  a  private_type_id  or  l_private_type_id. 

The  as  dscrmt  dec!  s  attribute  of  a  type_decl  node  is  a  possibly  empty 
sequence  containing  thi  discriminant  declarations  which  appear  in  the  type 
declaration;  for  declarations  of  derived  types  and  generic  formal  types  which 
are  not  private  this  sequence  is  always  empty. 

The  as  type  def  attribute  associated  with  a  type_decl  node  designates  a 
node  representing  the  portion  of  source  code  following  the  reserved  word  "is"; 
hence  the  as  type  def  attribute  for  an  incomplete  type  definition  is  void,  anc 
may  not  be  void  for  any  other  kind  of  type  declaration.  The  permitted  values  of 
the  as  type  def  attribute  for  the  remainder  of  the  type  declarations  are  as 
follows:  for  a  (limited)  private  type  declaration  --  a  private  def  or 
l__private_def  node;  for  a  generic  type  declaration  --  a  TYPE_DEF  node  having  the 
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prefix  "formal_'',  an  uncons trained_array_def  node,  a  constrained  array_def  node, 
or  an  access^dif  node;  for  a  derived  type  declaration  --  a  derived  node;  and 
finally,  for  a  full  type  declaration  --  an  enuaieration_def ,  integer_def, 
float  def,  fixed_def,  unconstrained_array_def ,  constrained_array”def , 
recor3_def,  or  acceis_def  node. 

The  subtype_decl  node  represents  a  subtype  declaration;  it  defines  two 
attributes:  as~source  name  and  as  subtype  indication.  The  former  denotes  a 
subtype_id  node, and  the  Tatter  a  subtype  W i cat 1 on  node.  The  subtype_id 
represents  the  defining  occurrence  of  the  subtype  name,  and  the 
subtype_indication  node  records  the  type  mark  and  constraint  appearing  in  the 
subtype”dec 1 arat ion. 

The  second  context  in  which  a  subtype_dec1  node  may  appear  is  as  a  part  of 
a  normalized  parameter  list  for  a  generic  instantiation,  in  which  case  the 
subtype_decl  node  does  not  represent  actual  source  code.  This  case  is  discussed 
in  more~detail  in  section  3.6. 1.1. 

The  task_decl  node  represents  the  declaration  of  either  a  task  type  or  a 
single  task  "object  with  an  anonymous  type,  depending  on  whether  or  not  the 
reserved  word  "type"  is  included  in  the  specification.  The  difference  is 
indicated  by  the  value  of  the  as  source  name  attribute  --  a  type_id  nooe  in  the 
former  case,  a  variable_id  node  in  the  latter.  The  as_decl_s  attribute  is  a 
possibly  empty  sequence  of  nodes  representing  the  entry  declarations  and 
representation  clauses  given  in  the  task  specification  (subprog_entry_dec1  and 
REP  nodes).  The  declaration  of  a  task  object  (or  objects)  of”a  named  type  is 
represented  by  a  variable_decl  node  rather  than  a  task_^dec1  node. 


3.1. 1.3.3. 1  SIMPLE_RENAME_OECL 

The  class  SIMPLE_RENAME_OECL  contains  nodes  representing  the  renaming  of  an 
object  or  an  exception.  The  renaming  of  an  entity  as  a  subprogram  or  a  package 
is  represented  by  a  subprog_entry_decl  node  or  a  package_decl  node, 
respectively. 

A  renaming  declaration  for  an  object  is  represented  by  a  renajnes_obj_decl 
node.  The  as  source  name  attribute  denotes  a  variable_id  or  a  constant_id, 
depending  on  the  kind  of  object  renamed.  A  constant  object~is  '■eorssented  by  a 
constant_id;  constant  objects  include  constants,  discriminants,  parameters  of 
mode  in, “loop  parameters,  and  components  of  constant  objects.  An  object  that 
does  not  belong  to  any  of  the  previous  categories  is  represented  by  a 
variab1e_id  (this  includes  objects  of  a  limited  type).  The  as  name  attribute  of 
a  renaiites_obj_dec1  node  denotes  a  node  of  type  NAME  which  represents  the  object 
being  renamed?  The  as  type  mark  name  attribute  references  a  selected  or 
used_naine_id  node  corresponding  to  the  type  mark  appearing  in  the  renaming 
declaration. 

The  renaines_obj_dec1  node  may  also  appear  in  a  normalized  parameter  list 
for  a  generic  instantiation.  This  case  does  not  correspond  to  source  code,  and 
is  discussed  in  detail  in  section  3. 6,1.1. 
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The  renaming  of  an  exception  is  represented  by  a  renames_exc_decl  node,  for 
which  the  as  source  name  attribute  always  designates  an”excipt1on_1d.  The 
as  name  attribute  can  Be  either  a  selected  node  or  a  used_naBe~1d  node 
corresponding  to  the  exception  being  renamed. 


3. 1.1. 3. 3. 2  UNIT_DECL 

The  class  UNIT_0ECL  represents  the  declaration  of  a  subprogram,  package, 
generic  unit,  or  entry.  The  as  header  attribute  which  is  defined  on  the  class 
references  a  HEADER  node,  the  type  of  which  is  determined  by  the  reserved  word 
appearing  in  the  declaration  (i.e.  "procedure",  "function",  "package",  or 
"entry") . 

The  generic_decl  node  corresponds  to  the  declaration  of  a  generic  unit. 
The  as  source  name  attribute  references  a  generic_id  representing  the  name  of 
the  generic  unit.  The  as  header  attribute  may  denote  a  procedure_spec,  a 
function_spec,  or  a  package_spec.  The  attribute  as  item  s  is  a  possibly  empty 
sequence”of  generic  formal  parameter  declarations  --  a  list  of  nodes  of  type  in, 
in_out,  type_decl,  or  subprog_entry_decl. 


3. 1.1. 3. 3. 2.1  MON_GENERIC_OECL 

The  class  NON_GENERIC  DECL  encompasses  subprogram,  package,  and  entry 
declarations.  The  as  unTt  kind  attribute  that  is  defined  on  the  class 
determines  the  kind  of  declaration  the  subprog  entry_^decl  or  package_decl  node 
represents:  a  renaming  .  declaration,  an  Instantiation,  a  generic  formal 
parameter  declaration,  or  an  "ordinary"  declaration. 

An  entry  (family)  declaration  is  represented  by  a  subprog^entry_decl  node 
for  which  the  as  source  name  attribute  is  an  entry^id,  the  as'*header  attribute 
is  an  entry  node,  and  the  as  unit  kind  attribute  is  void.  The  renaming  of  an 
entry  as  a  procedure  is  treated  as  a  procedure  declaration  (i.e.  the 
as  source  name  attribute  is  a  procedure_id,  not  an  entry_id). 

The  as  source  name  attribute  of  a  package_decl  node  will  always  designate  a 
package_iB^  and  the  sm  header  attribute  --  a  package_spec.  However,  the 
as  upit~kind  attribute  may  have  one  of  three  values;  renames  unit  (representing 
the  name  of  the  unit  being  renamed),  instantiation  (representing  the  name  of  the 
generic  unit  and  the  generic  actual  part),  or  void  (if  the  declaration  is  an 
"ordinary"  one). 

The  declaration  of  a  procedure,  a  function,  or  an  operator  is  represented 
by  a  subprog_entry_decl  node,  for  which  the  as  header  attribute  can  be  either  a 
procedure  spec  or  ~a  function_spec.  In  addition  to  the  three  values  of 
as  unit  kind  described  in  the  previous  paragraph,  the  as  unit  kind  attribute  of 
a  subprog_entry^decl  node  may  designate  a  node  from  class  GENER I C_PAIIAM  if  the 
subprogram  in  the  declaration  is  a  generic  formal  parameter.. 
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The  as  source  name  attribute  for  a  subprogram  declaration  is  a  node  from 
class  suBPROirNSHrr  with  one  exception.  A  declaration  renaming  an  enumeration 
literal  as  a  function  will  have  an  ENLW__L1TERAL  node  as  its  as  source  name 
attribute  (the  function_spec  node  denoted  by  the  as  header  attribute  wi i 1 
contain  an  empty  parameter  list).  For  all  other  declarations  the  type  of  node 
designated  by  the  as  source  name  attribute  is  determined  by  the  kind  of 
declaration  introducing  the  new  name  (i.e.  a  declaration  renaming  an  attribute 
as  a  function  will  have  a  function_1d  as  its  as  source  name  attribute). 

A  subprog_entry_decl  node  may  also  appear  in  a  normalized  parameter  list 
for  a  generic  instantiation.  In  this  case  the  declaration  will  always  be  a 
renaming  declaration  which  does  not  correspond  to  source  code  (see  section 
3.6. 1.1  for  details). 


3. 1.1. 3. 4  ID_S_0ECL 

The  ID_S_DECL  class  contains  nodes  corresponding  to  declarations  which  may 
define  mori  “than  one  entity  --  variable  declarations,  (deferred)  constant 
declarations,  record  component  declarations,  number  declarations,  and  exception 
declarations.  Although  any  of  these  declarations  may  introduce  a  single 
identifier,  a  node  from  class  ID  S_DECL  will  always  be  used  to  represent  the 
declaration,  never  a  node  from  class  ID_0ECL. 

An  exception_decl  node  represents  an  exception  declaration;  the 
as  source  name  s  attribute  designates  a  sequence  of  exception_id  nodes. 

A  deferred_constant_decl  node  denotes  a  deferred  constant  declaration.  The 
as  source  name  s  attribute  refers  to  a  sequence  of  constant_id  nodes;  each 
constant_Td  node  represents  the  first  defining  occurrence  of  the  associated 
identifier.  The  as  name  attribute  of  the  deferred_constant_decl  node  is  a 
used_name_id  or  selected  node  representing  the  type  mark  given  in  the 
declaration.  The  subsequent  full  declaration  of  the  deferred  constant(s)  will 
be  represented  by  a  constant  decl  node. 


3. 1.1. 3.4.1  EXP_DECL 

The  EXP_0ECL  class  represents  multiple  object  declarations  that  can  include 
an  initial  “value  --  number  declarations,  variable  declarations,  and  constant 
declarations. 

A  number  declaration  is  denoted  by  a  number_decl  node  for  which  the 
as_source_name_s  attribute  is  a  sequence  of  number  id  nodes,  and  the  as  exp 
attribute  references  a  node  corresponding  to  the  static~expression  given  in  the 
declaration. 
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3. 1.1. 3.4. 1.1  OBJECT_OECL 

Class  06JECT_DECL  represents  variable,  constant,  and  component 
declarations. 

A  variable_decl  node  represents  either  a  variable  declaration  in  a 
declarative  part  or  a  component  declaration  in  a  record  type  definition; 
as_source_na«e_s  is  a  sequence  of  var1able_id  nodes  or  component  id  nodes, 
respectively.  ~  The  as  exp  attribute  denotes~the  (default)  initial  vaTue,  and  is 
void  if  none  is  giveru  Tor  a  variable  declaration,  as  type  def  may  denote 
either  a  subtype  indication  node  or  a  cons trained_ar ray  def  node;  for  a 
component  declaration  as  type  def  refers  to  a  subtype_indi cation  node. 

A  constant_dec1  node  represents  a  full  constant  declaration.  The  attribute 
as  source  name  s  is  a  sequence  of  constant_id  nodes;  as  exp  represents  the 
initial  value.  The  as  type  def  attribute  may  denote  either  a"subtype_indication 
node  or  a  constra i ned_array_def  node. 

A  constant_dec1  node  may  also  appear  in  a  special  normalized  parameter 
sequence  for  a  generic  instantiation,  in  which  case  it  does  not  represent  source 
code  (see  section  3.6. 1.1  for  details). 

Unlike  other  object  declarations,  which  contain  named  types  only,  the 
declarations  in  class  0BJECT_DECL  may  introduce  anonymous  subtypes  via  a 
constrained  array  definition  or~the  inclusion  of  a  constraint  in  the  subtype 
indication.  If  the  object(s)  being  declared  are  of  a  named  type,  then  the 
sm  obj  type  attribute  of  each  defining  occurrence  node  in  the  as_source_name  s 
sequence  denotes  the  same  entity  --  the  TYPE__SPEC  node  referenced"'! n  the 
defining  occurrence  node  corresponding  to  the  type  mark. 

If  the  object  declaration  contains  an  anonymous  subtype  (i.e.  as  type  def 
denotes  a  constra ined_array_def  node  or  a  subtype  indication  node  with  a 
non-void  as  constraint  attribute)  then  a  different  TYPE_SPEC  node  will  be 
created  for  the  sm  obj  type  attribute  of  each  defining  occurrence  node  in  the 
as  source_name_s  sequence.  The  sm  is  anonymous  attribute  of  each  will  have  the 
value  TRUE.  ~If  the  constraint  is  non-static,  then  each  TYPE_SPEC  node 
references  its  own  copy  of  the  CONSTRAINT  node  corresponding  to  the  new 
constraint;  if  the  constraint  is  static  then  each  TYPE_SPEC  may  or  may  not 
reference  its  own  copy.  DIANA  does  not  require  that  the  nodi  referenced  by  the 
TYPE_0EF  attribute  of  the  0BJECT_DECL  node  have  a  unique  node  representing  the 
constraint,  even  if  the  constraint  is  non-static;  the  0BJECT_0ECL  node  is 
allowed  to  share  the  CONSTRAINT  node  with  one  of  the  TYPE  SPEC  nodes. 
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Section  3.2 


OEF  NAME 


3.2  OEF_NAME 

The  appearances  of  identifiers,  operators,  and  enumeration  characters  in  a 
DIANA  tree  are  divided  into  defining  and  used  occurrences;  the  class  DEF  NAME 
contains  all  of  the  nodes  representing  defining  occurrences.  Each  entity  o7  an 
Ada  program  has  a  defining  occurrence;  uses  of  the  name  or  symbol  denoting  the 
entity  always  refer  to  this  definition.  The  defining  occurrence  contains  the 
semantic  information  pertaining  to  the  associated  entity;  none  of  the  nodes  in 
class  DEF_NAME  have  any  structural  attributes. 

The  names  represented  by  this  class  fall  into  two  principal  categories: 
predefined  names  and  user-defined  names.  Defining  occurrences  corresponding  to 
user-defined  entities  are  introduced  by  the  as  source  name  or  as  source  name  s 
attribute  of  nodes  in  class  ITEM,  BLOCK^LOOP ,  LABEltD ,  and  FOR_REV.  Defining 
occurrences  associated  with  predefined  “entities  are  not  accessable  via 
structural  attributes  since  they  do  not  have  a  declaration  point. 

Each  node  in  class  0EF_NAME  has  an  lx  symrep  attribute  to  retain  the  source 
representation  of  the  identifier  or  character  literal  associated  with  the 
defining  occurrence.  Those  nodes  in  class  SOURCE_NAME  generally  have  lx  srcpos 
and  lx  comments  attributes  for  which  the  values  are  defined;  the  values  of  these 
attributes  are  undefined  for  nodes  in  class  PREDEF_NAME.  Certain  nodes  in  class 
SOURCE^NAME  may  be  used  to  represent  both  predefined  and  user-defined  names 
(nodes  such  as  exception_id) ;  however,  lx  srcpos  and  lx  comments  for  these  nodes 
are  undefined  when  representing  a  predefined  name. 

The  names  associated  with  certain  entities  may  have  more  than  one  point  of 
definition;  in  particular,  those  corresponding  to; 

(a)  deferred  constants 

(b)  incomplete  types 

(c)  non-generic  (limited)  private  types 

(d)  discriminants 

(e)  non-generic  formal  parameters 

(f)  program  units 
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For  these  names,  the  first  defining  occurrence  (which  is  indicated  by  the 
sm  first  attribute)  is  treated  as  THE  definition.  In  general,  all  references  to 
the  entity  refer  to  the  first  defining  occurrence,  and  the  multiple  defining 
occurrences  of  an  entity  all  have  the  same  attribute  values.  Types  and  deferred 
constants  present  special  cases  which  are  discussed  in  subsequent  sections. 


3.2.1  PREDEF_NAME 

The  nodes  in  class  PREDEF_MAME  correspond  to  the  names  of  entities  for 
which  the  Ada  language  does  not  provide  a  means  of  declaration;  consequently  a 
node  from  class  PREOEF_NAME  will  NEVER  be  designated  by  a  structural  attribute. 

The  nodes  attribute_id,  argument_id,  pragiiia_id,  bltn_operator_id,  and  void 
comprise  this  class,  "The  nodes  arguinent_id  (the  name  of  a  pragma  argument  or 
argument  value)  and  attribute_id  (the  name  of  an  Ada  attribute)  have  no 
attributes  other  than  lx  symrep.  The  pragma_id  represents  the  name  of  a  pragma. 
The  sm  argument  id  s  attribute  denotes  a  "sequence  of  argument  identifiers 
associated  with  the  pragma  (i.e.  the  sequence  for  pragma  LIST  contains  nodes 
denoting  the  argument  identifiers  ON  and  OFF);  if  a  particular  pragma  has  no 
argument  identifiers  the  sequence  is  empty.  The  node  bltn_operator_id 
corresponds  to  a  predefined  operator;  the  different  operators  are  dTstinguished 
by  the  sm  operator  attribute. 


3.2,2  SOURCE^NAME 

The  SOURCE_NAME  class  is  composed  of  those  nodes  corresponding  to  defining 
occurrences  of  entities  which  may  be  declared  by  the  user. 

The  exception_1d  node  represents  an  exception  name.  If  the  exception_id  is 
a  renaming  then  "the  sm  renames  attribute  is  a  used_name_id  or  a  selected  node 
denoting  the  original  exception  name  (the  node  which  is  designated  by  the 
as  name  attribute  of  the  renames_exc_decl  node).  If  the  exception  name  is  not 
introduced  by  a  renaming  declaration  then  sm  renames  is  void. 

An  entry  (family)  name  is  denoted  by  an  entry_id  node  which  has  two 
non-lexical  attributes  :  sm  spec  and  sm  address.  The  sm  spec  attribute 
references  the  entry  node  (which  contains  the  discrete  range  and  formal  part) 
designated  by  the  as  header  attribute  of  the  subprog_entry_decl  node.  The 
sm  address  attribute  denotes  the  expression  given  in  an  address  clause;  if  no 
address  clause  is  applicable  this  attribute  is  void. 


3.2.2. 1  LABEL_NAME 

The  class  LABEL_NAHE  represents  those  identifiers  associated  with 
statements;  the  sm  stm  attribute  defined  on  this  class  denotes  the  statement  to 
which  the  name  corresponds.  A  label_id  node  represents  the  name  of  a  statement 
label  and  is  introduced  by  a  labeled  node;  sm  stm  can  reference  any  node  in 
class  STM.  A  block_loop_id  represents  the  name  of  a  block  or  a  loop;  sm  stm 


DIANA  Reference  Manual  Draft  Revision  4 

SEMANTIC  SPECIFICATION 


Page  3-15 


denotes  the  block  or  loop  node  which  introduces  the  block_1oop_1d. 


3. 2. 2. 2  TYPE_NAME 

The  class  TYPE_MAME  contains  nodes  associated  with  the  names  of  types  or 
subtypes;  it  has  “an  sm  type  spec  attribute  attribute  defined  on  it.  Certain 
type  names  may  have  more  than  one  defining  occurrence;  in  particular,  those 
corresponding  to  private  and  limited  private  types  which  are  not  generic  formal 
types,  and  those  associated  with  incomplete  types. 

A  pr1vate_type_1d  or  l_private_type_1d  node  represents  the  defining 
occurrence  of  “a  type  name  introduced  by  a  (limited)  private  type  declaration; 
the  type  may  or  may  not  be  a  generic  formal  type.  A  pr1vate_type_id  or 
l_private_type_1d  node  has  an  sm  first  attribute  that  references  itself, “and  an 
sm  type  spec  attribute  denoting  a  private  or  l_pr1vate  node. 

If  the  (limited)  private  type  is  not  a  generic  formal  type  then  its  name 
has  a  second  defining  occurrence  corresponding  to  the  subsequent  full  type 
declaration.  The  second  defining  occurrence  is  represented  by  a  type_id  node; 
the  sm  first  attribute  references  the  private_type_id  or  l_private_type_id  node 
of  the  corresponding  (limited)  private  type  declaration,  and  the  ~sm  type  spec 
attribute  denotes  the  full  type  specification,  a  node  belonging  to  class 
FULL_TYPE_SPEC. 

Used  occurrences  of  a  (limited)  private  type  name  will  reference  the 
pr1vate_type_1d  or  1_private_type_1d  as  the  definition. 

Each  defining  occurrence  of  the  name  of  an  incomplete  type  is  represented 
by  a  type_id  node,  the  sm  first  attribute  of  which  denotes  the  type_1d  node 
corresponding  to  the  incomplete  type  declaration.  Ordinarily,  the  sm  type  spec 
attribute  of  the  type_id  nodes  for  both  the  incomplete  and  the  full  type 
declaration  refer  to  the  full  type  specification  --  a  node  from  class 
FULL_TYPE  SPEC.  The  single  exception  occurs  when  the  incomplete  type  is 
declared  '"’immediately  within  the  private  part  of  a  package”  [ARM,  section  3.8.1] 
and  the  package  body  containing  the  full  type  declaration  is  a  separate 
compilation  unit,  in  which  case  the  sm  type  spec  attribute  of  the  type_id 
corresponding  to  the  incomplete  type  declaration  denotes  an  incomplete  node. 

The  defining  occurrences  of  all  other  kinds  of  type  names  are  represented 
by  type_1d  nodes.  The  sm  first  attribute  references  the  node  which  contains  it, 
and  thi  sm  type  spec  attribute  denotes  a  node  belonging  to  the  class 
FULL_TYPE^5PEC7 

A  new  TYPE_SPEC  node  is  created  for  the  sm  type  spec  attribute  of  a  type_id 
node  unless  the  type_id  corresponds  to  an  incomplete  type  declaration  and  the 
full  type  declaration  is  in  the  same  compilation  unit.  A  new  private  or 
l_pr1vate  node  is  always  created  for  the  sm  type  spec  attribute  of  a 
pf ivate_type_id  or  l_pr1vate_type_id  node. 

A  subtype_id  node  represents  the  defining  occurrence  of  a  subtype  name;  its 
only  non-lexical  attribute  is  sm  type  spec,  which  references  the  appropriate 
subtype  specification.  If  the  subtype_id  is  introduced  by  a  subtype  declaration 
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1n  which  the  subtype  indication  contains  a  constraint  then  a  new  TYPE_SPEC  node 
is  created  to  represent  the  subtype  specification.  If  the  subtype  declaration 
does  not  impose  a  new  constraint  then  the  sm  type  spec  attribute  references  the 
TYPE_SPEC  node  associated  with  the  type  mark  appearing  in  the  declaration, 

A  subtype_1d  may  also  be  introduced  by  a  declarative  node  in  a  normalized 
parameter  list  for  a  generic  instantiation,  in  which  case  the  subtype  id  does 
not  correspond  to  source  code.  The  correct  values  for  its  attributes  Tn  this 
instance  are  defined  in  section  3.6. 1.1. 


3. 2. 2. 3  080ECT_NAME 

The  class  OBJECT_NAME  contains  nodes  representing  defining  occurrences  of 
entities  having  a~  value  and  a  type;  it  is  composed  of  iteration  id, 
EHUM_LITERAL,  and  INIT_OBJECT_MAME.  The  sm  obj  type  attribute  which  is  defined 
on  the  class  denotes  the  subtype  of  the  object  or  1 iteral . 

An  iteration_id  represents  the  defining  occurrence  of  a  loop  parameter,  and 
is  introduced  by  an  iteration  node.  The  sm  obj  type  attribute  references  tne 
enumeration  or  integer  node  denoted  by  the  sm  base  type  attribute  of  tne 
OISCRETE_RANGE  node  associated  with  the  iteration  scheme. 


3. 2. 2. 3.1  ENUM_HTERAL 

The  class  ENUM_LITERAL  is  composed  of  nodes  representing  the  defining 
occurrences  of  literals  associated  with  an  enumeration  type.  The  nodes 
enumeration^ld  and  character_1d  comprise  this  class  --  enumeration_id 
corresponds^to  an  identifier,  character_id  to  a  character  literal. 

ENUM_LITERAL  defines  the  attributes  sm  pos  and  sm  rep,  both  of  which  are  of 
type  Intiger.  The  attribute  sm  pos  contains  the  value  of  the  predefined  Ada 
attribute  POS,  i.e.  the  universal  Integer  corresponding  to  the  actual  position 
number  of  the  enumeration  literal.  The  sm  rep  attribute  contains  the  value  of 
the  predefined  Ada  attribute  VAL;  the  user  may  set  this  value  with  an 
enumeration  representation  clause.  If  no  such  clause  is  in  effect,  the  value  of 
sm  rep  will  be  the  same  as  that  of  sm  pos.  The  sm  opj  type  attribute  references 
the  enumeration  node  corresponding  to  the  enumeration  type  to  which  the  literal 
belongs. 

An  ENUM_LITERAL  node  may  be  introduced  by  either  an  enumeration_def  node  or 
a  subprog_entry_decl  node.  The  latter  corresponds  to  the  renaming  of  an 
enumeration  literal  as  a  function,  in  which  case  the  semantic  attributes  of  the 
ENUM_LITERAL  node  will  have  the  same  values  as  those  of  the  node  corresponding 
to  the  original  literal. 

An  ENUM_LITERAL  node  may  be  introduced  by  a  declarative  node  in  a  special 
normalized  parameter  list  for  a  generic  instantiation;  in  this  instance  the 
ENUM  LITERAL  node  does  not  correspond  to  source  code.  This  case  is  discussed  in 
detail  in  section  3.6. 1.1. 
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3. 2. 2. 3. 2  INIT_08JECT_NAME 

The  class  IMIT_MJECT  NAME  contains  nodes  corresponding  to  defining 
occurrences  of  objects  whicfJ  may  have  an  initial  value;  it  defines  an  attribute 
sm  init  exp  to  record  this  value.  This  attribute  represents  those  (default) 
initial  vilues  which  are  explicitly  given;  i.e.  the  default  value  NULL  for  an 
access  object  is  not  represented  by  sm  init  exp  unless  it  is  explicitly 
specified  in  the  source  code.  The  objects  denoted  by  the  nodes  of  this  class 
include  named  numbers,  variables,  constants,  record  components,  and  formal 
parameters. 

The  node  nuraber_id  represents  the  definition  of  a  named  number.  The 
sm  obj  type  attribute  denotes  a  uniwersal_integer  or  universal_real  node,  and 
the  sm  imt  exp  attribute  references  the  node  denoted  by  the  as  exp  attribute  of 
the  corresponding  nunber_decl  node. 


3. 2. 2. 3. 2.1  VC_NAME 

The  class  VC_NAME  is  composed  of  the  nodes  variable  id  and  constant_id, 
denoting  the  names  of  variables  and  constants,  respectively.  The  attributes 
sm  renames  obj  and  sm  address  are  defined  for  the  nodes  in  this  class. 

The  sm  renames  obj  attribute  is  of  type  Boolean,  and  indicates  whether  or 
not  the  name  of  the  object  is  a  renaming;  the  value  of  this  attribute  determines 
the  meaning  of  the  sm  init  exp  attribute  for  nodes  in  this  class.  If  the  name 
is  introduced  by  a  renaming  declaration  then  sm  init  exp  denotes  the  NAME  node 
referenced  by  the  as  name  attribute  of  the  renaiiies_obj_decl  node.  Otherwise, 
sm  igit  ey  is  the  EXP  node  designated  by  the  as  exp  attribute  of  the  associated 
0BJECT_DECL  node,  and  consequently  may  be  void. 

The  sm  address  attribute  denotes  the  expression  for  the  address  of  the 
object  as  given  in  an  address  clause;  if  no  such  clause  is  applicable  sm  address 
is  void.  In  the  case  of  a  renaming,  the  value  of  the  sm  address  attribute  is 
determined  by  the  original  object;  if  the  original  object  cannot  be  named  in  an 
address  clause  then  sm  address  is  void. 

For  a  VC_NAME  node  corresponding  to  an  ordinary  object  dec'!a''aticn  the 
sm  obj  type  attr-'bute  denotes  either  the  TYPE  SPEC  node  corresponding  to  the 
type  mark  in  the  declaration,  or  an  anonymous  TYPE_SPEC  node  if  the  declaration 
contains  a  constrained  array  definition  or  a”  constraint  in  the  subtype 
indication.  If  the  variab1e_id  or  constant_id  is  introduced  by  a 
renames_obj_decl  node,  then  sm  obj  type  is  the  TYPE_SPEC  node  corresponding  to 
the  subtype  of  the  original  object  (hence  this  ~TYPE_SPEC  node  does  not 
necessarily  correspond  to  the  type  mark  in  the  renaming  declaration,  although  it 
will  have  the  same  base  type). 

A  constant_id  represents  the  name  of  a  constant  object.  A  constant  object 
may  be  either  a  (deferred)  constant  or  the  renaming  of  one  of  the  following:  a 
(deferred)  constant,  a  discriminant,  a  loop  parameter,  a  (generic)  formal 
parameter  of  mode  in,  or  a  component  of  a  constant  object.  The  sm  first 
attribute  references  the  constant_id  node  corresponding  to  the  first  defining 
occurrence  of  the  associated  name.  For  a  constant  id  node  associated  with  the 
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full  declaration  of  a  deferred  constant  this  attribute  will  reference  the 
constant_id  corresponding  to  the  deferred  declaration;  for  all  other  constant_id 
nodes  thi  sm  first  attribute  will  contain  a  self -reference. 

The  attributes  of  the  constant_1d  nodes  representing  the  defining 
occurrences  of  a  deferred  constant  “have  the  same  values.  The  sm  obj  type 
attribute  designates  a  private  or  1_private  node,  and  sm  init  exp  denotes  the 
initialization  expression  given  in  the  full  constant  declaration.  Used 
occurrences  of  a  deferred  constant  name  reference  the  constant_id  of  the 
deferred  declaration. 

The  variable_id  node  represents  the  name  of  an  object  which  is  declared  in 
an  object  declaration  or  a  renaming  declaration  but  is  not  a  constant  object. 
The  sm  is  shared  attribute  has  a  Boolean  value  indicating  whether  or  not  a 
shared  pragma  has  been  applied  to  the  variable.  If  the  variable  id  represents  a 
renaming  then  sm  is  shared  indicates  whether  or  not  the  original  object  is 
shared. 

Both  the  constant_1d  and  the  variable  iJ  nodes  majr  be  introduced  by 
declarative  nodes  in  a~normalized  parameter  list  for  a  generic  instantiation,  in 
which  case  they  do  not  represent  source  code.  The  appropriate  values  for  the 
attributes  of  each  are  discussed  in  section  3.6. 1.1. 


3. 2. 2. 3. 2. 2  C0MP_NAME 

The  nodes  component  id  and  discriminant  id  comprise  the  class  COMP^^NAME, 
which  represents  the  defining  occurrences  oT  identifiers  associated  with  record 
components  and  record  discriminants.  The  attribute  sm  comp  rep  is  defined  for 
the  nodes  in  this  class;  it  references  the  node  corresponding  to  the  applicable 
component  representation  clause,  and  is  void  if  no  such  clause  exists.  The 
attribute  sm_comp_rep  can  never  denote  a  comp_rep_pragma  node. 

The  sm  init  exp  attribute  represents  the  default  initial  value,  referencing 
the  EXP  node  designated  by  the  as  exp  attribute  of  the  variable_decl  or 
dscrmt_decl  node  (hence  sm  init  exp  can  be  void). 

Unlike  component  names,  discriminant  names  may  have  multiple  defining 
occurrences ,  therefore  an  sm  first  attr-bute  is  defined  for  the  discriminant_id 
node  (the  instance  of  a  component  name  m  a  component  representation  clause  is 
considered  to  be  a  used  occurrence  rather  than  a  defining  occurrence).  If  an 
incomplete  or  non-generic  (limited)  private  declaration  contains  a  discriminant 
part,  the  discriminants  will  have  a  second  definition  point  at  the  full  type 
declaration;  the  sm  first  attribute  of  both  discriminant_id  nodes  will  reference 
the  discrirainant^id  node  corresponding  to  the  earl ier“incomplete  or  (limited) 
private  declaration. 


3. 2. 2. 3. 2. 3  PARAM_NAME 

The  class  PARAM_NAME  contains  nodes  corresponding  to  the  names  of  formal 
parameters  declared”  in  the  formal  parts  of  subprograms,  entries,  accept 
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statements,  and  generic  units.  The  nodes  In  Id,  In  outbid,  and  out_1d  comprise 
PARAM^NAME,  represent  ing  parameters  of  mo3e  in,  Tn  out,  and  out,  respectively 
(an  out_1d  node  can  never  be  used  to  represent  a  generic  formal  object). 

The  attribute  sm  init  exp  records  the  initial  value;  it  denotes  the  EXP 
node  referenced  by  t(ie  as  exp  attribute  of  the  corresponding  in,  1n_out,  or  out 
node.  The  attribute  sm  init  exp  is  void  for  1n_out_1d  and  out_1d  nodes. 

Formal  parameters  associated  with  subprogram  declarations,  entry 
declarations,  and  accept  statements  may  have  more  than  one  defining  occurrence. 
The  sm  first  attribute  for  a  PARAM_NAME  node  belonging  to  an  entry  declaration 
or  an  accept  statement  will  always  reference  the  PARAM_NAME  node  of  the  entry 
declaration.  The  sm  first  attribute  of  a  PARAM_NAME  node  corresponding  to  a 
subprogram  name  denotes  the  PARAM_NAME  node  of”the  subprogram  declaration,  body 
declaration,  or  stub  declaration  which  first  introduces  the  identifier. 


3. 2. 2. 4  UNIT_NAME 

The  class  UNIT_NAME  represents  the  defining  occur»-ences  of  those 
identifiers  and  symbols  associated  with  program  units;  it  contains  the  nodes 

task_body_id,  gener1c_id,  and  pacl(age_1d,  as  well  as  the  class  SUBPROG_NAME . 

The  task  body_1d  node  denotes  a  task  unit  name  introduced  by  the 
declaration  o?  a  body  or  a  stub.  The  sm  first  attribute  references  the  type^id 
or  var1able_1d  node  (depending  on  whether  or  not  the  task  type  is  anonymous)  ”of 
the  task  specification.  The  sm  type  spec  attribute  denotes  the  task_spec  node 
denoted  by  either  the  smtype  spec  attribute  of  the  type_id  node  or  the 
sm  obj  type  attribute  of  the  variable_1d  node. 

If  the  body  of  the  task  is  in  the  same  compilation  unit  then  the  sm  body 
attribute  of  the  task  body_1d  references  the  bodv  (‘  block_body  node).  If  the 
body  is  in  another  compilation  unit,  but  the  stub  is  not,  then  sm  body  denotes 
the  stub  (a  stub  node).  Otherwise  sm  body  is  void. 


3. 2. 2. 4.1  NON_TASK_NAME 

The  nodes  in  class  N0N_TASK  NAME  correspond  to  the  names  of  program  units 
which  are  not  tasks.  The  node  generic_1d  and  the  class  SUBPROG  PACK  NAME 
comprise  this  class. 

The  gener1c_1d  node  corresponds  to  the  defining  occurrence  of  the  name  of  a 
generic  unit  (the  name  of  an  instantiated  unit  is  represented  by  a  member  cf 
class  SUBPR06_PACK_NAME ) .  The  sm  first  attribute  of  a  gener1c_1d  always 
references  the  gener1c_1d  of  the  generic  specification.  The  sm  spec  attribute 
denotes  the  procedure_spec,  functlon^spec,  or  package_spec  associated  with  the 
subprogram  or  package  specification.  The  attribute  sm  generic  param  s 
represents  the  formal  part  of  the  generic  specification,  and  references  the  same 
sequence  as  the  as  item  s  attribute  of  the  corresponding  generic_decl  node.  The 
sm  is  inline  attribute  indicates  whether  or  not  an  INLINE  pragma  has  been  given 
for  the  ^neric  unit.  The, value  of  the  sm  body  attribute  is  determined  in  the 
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same  manner  as  the  sm  body  attribute  of  the  task_body_1d  node  (discussed  in  the 
previous  section). 


3. 2. 2. 4. 1.1  SUBPR06_PACK_MAME 

Defining  occurrences  of  packages  and  subprograms  are  represented  by  members 
of  class  SUBPR06_PACK_NAME .  The  attributes  sm  address  and  sm  unit  desc  are 
defined  on  this  class.  “The  sm  address  attribute  records  the  expression  given  in 
an  address  clause  for  the  unit,  if  such  a  clause  does  not  exist  then  sm  address 
is  void.  The  sm  unit  desc  attribute  is  a  multi-purpose  attribute;  in  some  cases 
it  is  used  to  indicate  that  a  particular  unit  is  a  special  case  (such  as  a 
renaming),  in  others  it  is  used  as  a  “shortcut"  to  another  node  (such  as  the 
unit  body). 

The  node  package_1d  represents  the  defining  occurrence  of  a  package;  its 
sm  spec  attribute  denotes  a  package_spec  node.  If  the  package_id  does  not 
correspond  to  a  renaming  or  an  instantiation  then  sm  spec  references  the 
package_spec  designated  by  the  as  header  attribute  of  the  package_decl  node, 
sm  first  references  the  package_TB  ^  the  package  specification,  and 
sm  unit  desc  denotes  a  node  from  class  BODY  (the  value  of  this  attribute  is 
determined  in  the  same  manner  as  the  value  of  the  sm  body  attribute  of  the 
task_body_id,  which  is  discussed  in  section  3. 2. 2. 4). 

If  the  package_id  corresponds  to  a  renaming  then  the  sm  unit  desc  attribute 
references  a  renames_unit  node  which  provides  access  to  the  original  unit.  The 
sm  first  attribute  of”  the  package_id  contains  a  self-reference,  while  the 
sm  spec  and  sm  address  attributes  have  the  same  values  as  those  of  the  original 
package. 

If  the  package_id  is  introduced  by  an  instantiation  then  sm  unit  desc 
designates  an  instantiation  node  containing  the  generic  actual  part  as  we iT as  a 
normalized  parameter  list.  The  sm  first  attribute  of  the  package^id  contains  a 
self-reference;  the  value  of  sm  address  is  determined  by  the  existence  of  an 
address  clause  for  the  instantiated  package,  consequently  it  may  be  void.  The 
sm  spec  attribute  references  a  new  package_spec  node  that  is  created  by  copying 
the  specification  of  the  generic  unit  and  replacing  every  occurrence  of  a  formal 
parameter  by  a  reference  to  a  an  entity  in  the  normalized  paramete*'  lis*:.  "’'he 
construction  of  the  new  specification  is  discussed  in  further  detail  in  section 
3.6. 1.1. 


3. 2. 2. 4. 1.1.1  SUBPROG_NAME 

The  class  SUBPROG_NAME  represents  defining  occurrences  of  subprograms;  it 
comprises  the  nodes  pfocedure_id,  function_id,  and  operator_id.  The  attributes 
sm  is  inline  and  sm  interface  are  defined  for  the  nodes  in”  this  class.  The 
sm  is  Ini ine  attribute  has  a  boolean  value  which  indicates  whether  or  not  an 
DiLlNf  pragma  has  been  given  for  the  subprogram.  If  an  INTERFACE  pragma  is 
given  for  the  subprogram  then  sm  interface  denotes  the  pragma,  otherwise  it  is 
void. 
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The  procedure_id  node  corresponds  to  a  defining  occurrence  of  a  procedure 
or  an  entry  renamed  as  a  procedure;  its  sm  spec  attribute  references  a 
procedure_spec  node.  In  addition  to  representing  a  function,  a  funct1on_1d  may 
represent”  an  attribute  or  operator  renamed  as  a  function.  An  operator_id  may 
denote  an  operator  or  a  function  renamed  as  as  operator.  The  sm  spec  attribute 
of  a  function_id  or  an  operator_1d  designates  a  funct1on_spec  node. 

If  the  SUBPR06__NAME  node  is  Introduced  by  an  "ordinary"  declaration  then 
sm  unit  desc  denotes  a  member  of  class  BODY,  and  sm  spec  references  the  HEADER 
node  denoted  by  the  as  deader  attribute  of  the  associated  subprog_entry_dec1 
node.  The  appropriate  BODY  node  is  selected  in  the  manner  descriBed  for  the 
sm  body  attribute  of  the  task_body_1d  node  in  section  3, 2. 2. 4. 

Like  a  package^id,  a  SUBPR06_NAME  node  may  be  introduced  by  a  renaming 
declaration,  in  which  case  sm  unit  desc  denotes  a  renaiiies_unit  node  and  sm  first 
contains  a  self-reference.  However,  the  sm  spec  attribute  of  the  Sl)BPRO(a_NAME 
node  does  not  denote  the  specification  of  the  original  unit,  but  that  of  the 
renaming  declaration.  The  values  of  the  attributes  sm  address,  sm  is  inline, 
and  sm  interface  are  the  same  as  those  of  the  original  unit. 

The  instantiation  of  a  subprogram  is  treated  in  the  same  manner  as  the 
instantiation  of  a  package.  The  sm  unit  desc  attribute  denotes  an  instantiation 
node,  sm  first  contains  a  self-reference,  and  a  new  procedure_spec  or 
function  spec  is  constructed  in  the  manner  described  in  section  3.671.1.  The 
values  o7  sm  address  and  sm  interface  are  determined  by  the  presence  of  an 
associated  address  clause  or  INTERFACE  pragma;  either  may  be  void.  The 
sm  is  inline  attribute  is  true  if  an  INLINE  pragma  is  given  for  the  generic  unit 
OR  the  instantiated  unit. 

A  SUBPROG_NAME  node  may  also  represent  a  generic  formal  parameter,  in  which 
case  sm  unit  desc  denotes  a  node  belonging  to  class  GENERIC_PARAM,  the  sm  first 
attribute  contains  a  self-reference,  and  sm  spec  denotes  the  HEADER  node 
introduced  by  the  generic  parameter  declaration.  The  attributes  sm  address  and 
sm  interface  are  void,  and  sm  is  inline  is  false. 

The  sm  unit  desc  attribute  of  an  operator_id  may  reference  an 
impl icit_not_eq  node,  which  indicates  that  the  inequality  operator  has  been 
declared'imoTicitly  by  the  user  through  the  declaration  of  an  equality  operator. 
The  inequality  operator  is  not  the  predefined  operator,  but  because  it  cannot  be 
explicitly  declared  it  has  no  corresponding  body,  hence  that  of  the 
corresponding  equality  operator  must  be  utilized.  Access  to  the  equality 
operator  is  provided  by  the  impl icit_not_eq  node.  An  operator_id  which  contains 
a  reference  to  an  implicit_not_eq  node  can  be  denoted  "only  by  semantic 
attributes. 

The  sm  spec  attribute  of  an  operdtor_id  representing  an  implicitly  declared 
inequality  operator  may  reference  either~the  function_spec  of  the  corresponding 
equality  operator  or  a  copy  of  it.  The  attribute  sm  address  is  void, 
sm  interface  has  the  same  value  as  the  sm  interface  attribute  of  the 
corresponding  equality  operator,  and  the  value  of  sm  is  inline  is  determined  by 
whether  or  not  an  INLINE  pragma  is  given  for  the  implicitly  declared  inequality 
operator. 
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The  sm  unit  desc  attribute  of  a  SUBPROG_NAME  node  may  reference  a 
der 1 ved_subprog  node,  in  which  case  the  procedure  or  function  is  a  derived 
subprogram.  The  specification  of  the  derived  subprogram  is  obtained  by  copying 
that  of  the  corresponding  subprogram  of  the  parent  type,  and  making  the 
following  substitutions: 

(a)  each  reference  to  the  parent  type  is  replaced  by  a  reference  to  the 
derived  type 

(b)  each  reference  to  a  subtype  of  the  parent  type  is  replaced  by  a 
reference  to  the  derived  type 

(c)  each  expression  of  the  parent  type  is  replaced  by  a  type  conversion 
which  has  the  expression  as  the  operand  and  the  derived  type  as  the 
target  type. 


The  remaining  attributes  have  the  following  values:  sm  address  is  void, 
sm  interface  has  the  same  value  as  the  sm  interface  attribute  of  the 
corresponding  derivable  subprogram,  and  the  value  of  sm  is  inline  is  determined 
by  the  existence  of  an  INLINE  pragma  for  the  derived  subprogram. 

The  nodes  in  class  SU8PROG_NAME  may  be  introduced  by  declarative  nodes  in  a 
normalized  parameter  list  constructed  for  a  generic  instantiation,  in  which  case 
they  do  not  correspond  to  source  code.  A  more  detailed  discussion  may  be  found 
in  section  3. 6. 1.1. 
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type  spec 


3.3  TYPE_SPEC 

The  classes  TYPE_SPEC  and  TYPE_DEF  are  complementary  --  the  former 
represents  the  semantic~concept  of  an  Ada  type  or  subtype,  the  latter  represents 
the  syntax  o^  the  declaration  of  an  Ada  type  or  subtype.  A  TYPE_SPEC  noae  does 
not  represent  source  code;  it  has  no  lexical  or  structural  attributes,  only 
semantic  attributes  and  code  attributes,  A  TYPE_DEF  node  has  no  other  purpose 
than  to  record  source  rode,  containing  only  lexical  and  structural  attributes. 
A  node  from  class  TYPE  SPfC  will  NEVER  be  designated  by  a  structural  attribute, 
a  node  from  class  TYPt_DEF  node  will  NEVER  be  designated  by  a  semantic 
attribute. 

Each  distinct  type  or  subtype  is  represented  by  a  distinct  node  from  class 
TYPE_SPEC;  furthermore,  there  are  never  two  TYPE_SPEC  nodes  for  the  same  entity. 
Although  anonymous  type  and  subtype  declarations~are  not  represented  in  DIANA, 
the  anonymous  types  and  subtypes  are  themselves  represented  by  nodes  from  class 
TYPE_SPEC. 

The  nodes  univ8rsal_integer,  universal_real ,  and  universal_float  represent 
the  universal  types;  they  have  no  attributes. 

The  incomplete  node  represents  a  special  kind  of  incomplete  tvpe. 
Ordinarily  incomplete  types  are  not  represented  by  TYPE^SPEC  nodes,  all 
references  are  to  the  full  type  specification.  The  sole  exception  occurs  when 
an  incomplete  type  declaration  is  given  in  the  private  part  of  the  package,  and 
the  subsequent  full  type  declaration  appears  in  the  package  body,  which  is  in  a 
separate  compilation  unit.  In  this  case  the  incomplete  type  is  represented  by 
an  incomplete  node,  and  all  references  denote  this  node  rather  than  the  full 
type  specification.  The  incomplete  node  defines  an  sm  discriminant  s  attribute 
wnich  aenotes  the  sequence  of  discriminant  declarations  designated  by  tne 
as  dscrmt  decl  s  attribute  of  the  type_decl  node  introducing  the  incomplete 
type.  This  sequence  may  be  empty. 


3.3.1  DERIVABLE_SPEC 

The  class  OERIVABLE_SPEC  consists  of  nodes  representing  types  which  may  be 
derived.  The  attribute~sm  derived  which  is  defined  on  this  class  refers  to  the 
parent  type  if  the  type  is  derived;  otherwise  it  is  void.  The  sm  derived 
attribute  is  void  for  a  subtype  of  a  derived  type.  The  nodes  in  this  class  also 
have  a  boolean  attribute,  sm  is  anonymous,  which  indicates  whether  or  not  the 
type  or  subtype  has  a  name. 
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A  derived  type  is  always  represented  by  a  new  node  corresponding  to  a  new 
base  type  (the  node  is  the  same  kind  as  that  of  the  parent  type).  If  the 
constraints  on  the  parent  type  are  not  identical  to  those  on  the  parent  subtype 
then  the  base  type  is  anonymous,  and  a  new  node  corresponding  to  a  subtype  of 
that  type  is  also  created.  The  node  associated  with  the  subtype  records  the 
additional  constraint  (the  constraint  may  be  given  explicitly  in  the  derived 
type  definition  or  implicitly  by  the  type  mark). 

In  addition  to  being  created  by  a  derived  type  definition,  a  derived  type 
may  be  introduced  by  a  numeric  type  definition.  The  base  type  of  a  user-defined 
numeric  type  is  an  anonymous  derived  type  represented  by  the  appr^p'^'i ate 
integer,  float,  or  fixed  node.  The  sm  derived  attribute  of  the  node  for  the 
anonymous  base  type  refers  to  the  node  corresponding  to  the  appropriate 
predefined  type. 

If  a  derived  type  is  an  enumeration  type  then  a  sequence  of  new  enumeration 
literals  is  created  for  the  derived  type,  unless  the  parent  type  is  a  generic 
formal  type.  The  value  of  sm  pos  in  each  new  ENUM_LITERAL  node  is  the  same  as 
that  in  the  corresponding  node  from  the  parent  type;  however,  the  sm  obj  type 
attribute  denotes  the  enumeration  node  for  the  derived  type.  The  value  of 
sm  rep  depends  on  whether  or  not  a  representation  clause  is  given  for  the 
derived  type;  if  not,  the  value  is  taken  from  the  corresponding  node  from  the 
parent  type. 

If  a  derived  type  is  a  record  type  and  a  representation  clause  is  given  for 
that  derived  type,  then  a  sequence  of  new  discriminants  and  a  sequence  of  new 
record  components  are  created  for  the  derived  type.  If  a  representation  clause 
is  not  given  for  the  derived  record  type  then  construction  of  the  new  sequences 
is  optional.  Excluding  sm  comp  rep,  the  values  of  all  of  the  attributes  in  each 
new  C0MP_MAME  node  will  be  the  same  as  those  in  the  corresponding  node  from  the 
parent  type;  sm  comp  rep  will  be  the  same  only  if  no  representation  clause  is 
given  for  the  derived  type. 

Certain  members  of  class  DERIVABLE_SPEC  may  represent  generic  formal  types. 
The  attributes  of  these  nodes  reflect  the  properties  of  the  generic  formal 
types,  not  those  of  the  corresponding  actual  subtypes.  For  instance,  the 
sm  size  attribute  of  an  array  nodp  corresponding  to  a  generic  formal  array  type 
isalways  void,  reflecting  the  fact  that  a  representation  clause  cannot  be  given 
for  a  generic  type.  The  value  of  this  attribute  implies  nothing  about  the  value 
of  this  attribute  in  the  array  node  of  a  corresponding  actual  subtype.  '^he 
values  of  attributes  having  a  uniform  value  when  corresponding  to  generic  formal 
types  are  discussed  in  the  appropriate  sections. 

The  sm  derived  attribute  of  a  DERIVABLE_SPEC  node  representing  a  generic 
formal  typeis  always  void,  and  sm  is  anonymous  is  always  false. 


3. 3. 1.1  PRIVATE_SPEC 

The  nodes  in  class  PRIVATE_SPEC  --  private  and  1  private  --  represent 
private  and  limited  private  types,  respectively.  The  attributes 
sm  discriminant  s  and  sm  type  spec  are  defined  for  these  nodes.  The 
sm~discriminant~s  attribute  references  the  sequence  of  discriminant  declarations 
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introduced  by  the  (limited)  private  type  dec''aration;  hence  it  may  be  empty. 
The  sm  type  spec  attribute  designates  the  full  type  specification  (a  node  from 
class  E'OLL_tVPE_SPEC)  unless  the  node  corresponds  to  a  generic  formal  private 
type,  in  which  case  the  value  of  sm  type  spec  is  undefined. 

A  subtype  or  derived  type  declaration  which  imposes  a  new  constraint  on  a 
(limited)  private  type  results  in  the  creation  of  a  constrained_record  node  if 
the  declaration  occurs  in  the  visible  part  or  outside  of  the  package;  if  the 
declaration  occurs  in  the  private  part  or  th?  package  body  then  a  node  from 
class  CONSTRAINED  or  class  SCALAR  is  created.  The  sm  base  type  attribute  of  the 
new  node  references  the  private  or  l_private  node  associated  with  the  type  mark. 

An  attribute  of  type  TYPE_SPEC  that  denotes  a  (limited)  private  type  always 
references  the  private  or  l“private  node.  Access  to  the  associated  full  type 
specification  is  provided  by  the  sm  type  spec  attribute  of  the  PRIVATE_SPEC 
node. 


3.3. 1.2  FULL_TYPE_SPEC 

The  class  FULL_TYPE  SPEC  represents  types  which  are  fully  specified.  The 
node  task_spec  and  the  cTass  N0N_TASIC  comprise  FULL_TYPE_SPEC. 

The  task_spec  node  represents  a  task  type.  A  task  type  may  be  anonymous  if 
the  reserved"  word  "type"  is  omitted  from  the  task  specification,  in  which  case 
the  task__spec  node  will  be  introduced  by  the  sm  obj  type  attribute  of  a 
variable^id  rather  than  the  sm  type  spec  attribute  of  a  type_id. 

The  task_spec  node  defines  five  additional  semantic  attributes:  sm  decl  s. 
sm  body,  sm  address,  sm  size,  and  sm  storage  size.  The  sm  decl  s  attrioute 
denotes  the  sequence  of  entry  declarations  and  representation  clauses  designated 
by  the  as  decl  s  attribute  of  the  associated  task_decl  nooe.  The  attrioute 
sm  body  denotes  the  block  body  node  corresponding  to  the  task  body  'fit  is  in 
the  same  compilation  unit;  if  not,  sm  body  refers  to  the  stub  node  if  the  stub 
is  in  the  same  compilation  unit;  if  neither  the  body  nor  the  stub  is  in  the  same 
compilation  unit,  then  sm  body  is  void.  Each  of  the  remaining  semantic 
attributes  (sm  address,  sm  size,  and  sm  storage  size)  denotes  the  EXP  node  of 
the  corresponding  representation  clause,  if  one  exists;  otherwise  it  is  void. 


3. 3. 1.2.1  H0N_TASK 

Class  NON_TASK  represents  fully  specified  types  which  are  not  tasks.  The 
nodes  in  this  class  are  used  to  denote  both  types  and  subtypes.  The  attribute 
sm  base  type  which  is  defined  on  this  class  references  the  base  type  --  a  node 
containing  all  of  the  representation  information.  The  sm  base  type  attribute  of 
a  N0N_TASK  node  representing  a  generic  formal  type  always  contains  a 
self-reference.  The  classes  SCALAR,  UNCONSTRAINED,  and  CONSTRAINED  comprise 
NON  TASK. 
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3. 3. 1.2. 1.1  SCALAR 

The  nodes  in  class  SCALAR  represent  scalar  types  and  subtypes.  A  scalar 
subtype  is  denoted  by  the  same  kind  of  node  as  the  type  from  which  it  is 
constructed  (unless  it  is  constructed  from  a  private  type);  however,  a  type  may 
always  be  distinguished  from  a  subtype  by  the  fact  that  the  sm  base  type 
attribute  of  a  node  corresponding  to  a  type  references  itself. 

The  SCALAR  class  has  an  sm  range  attribute  which  references  a  node 
corresponding  to  the  applicable  range  constraint.  In  most  cases  this  nooe 
already  exists  (the  source  code  has  supplied  a  constraint,  or  the  range  from  the 
appropriate  predefined  type  is  applicable);  however,  in  certain  instances  a  new 
range  node  must  be  constructed. 

A  new  range  node  is  created  for  an  enumeration  node  introduced  by  either  an 
enumeration  type  definition  or  a  derived  type  definition  which  does  not  impose  a 
constraint.  The  as  expl  and  as  exp2  attributes  of  the  range  node  denote 
USED_OBJECT  nodes  corresponding  to  the  first  and  last  values  of  the  enumeration 
type?  A  new  RANGE  node  is  also  created  when  more  than  one  object  is  declared  in 
an  object  declaration  containing  an  anonymous  subtype  with  a  non-static  range 
constraint.  The  subtypes  of  the  objects  do  not  share  the  same  RANGE  node  in 
this  case;  a  new  copy  of  the  RANGE  node  is  made  for  the  new  subtype  of  eacn 
additional  object  in  the  declaration  (if  the  constraint  is  static,  the  copy  is 
optional ) . 

The  attribute  cd  impl  size  which  is  defined  on  this  class  contains  the 
universal  integer  value  of  the  Ada  attribute  SIZE;  it  may  be  less  than  a 
user-defined  size. 

The  nodes  in  class  SCALAR  may  also  represent  generic  formal  scalar  types. 
The  enumeration  node  represents  a  formal  discrete  type;  the  integer  node  a 
formal  integer  type;  the  float  node  a  formal  floating  point  type;  and  the  fixed 
node  a  formal  fixed  point  type.  The  sm  range  attribute  for  a  generic  formal 
scalar  type  is  undefined. 

The  node  enumeration  represents  an  enumeration  type.  If  the  type  is  not  a 
generic  formal  type  then  the  sm  literal  s  attribute  references  the  sequence  of 
enumeration  literals  --  either  the  sequence  denoted  by  the  as  enum  literal  s 
attribute  of  the  enumeration  def  node  or  a  new  sequence  of  literals  createa  for 
a  derived  type.  If  the  enumeration  node  represents  a  generic  forma’  type  then 
sm  literal  s  denotes  an  empty  sequence. 

The  integer  node  represents  an  integer  type;  it  defines  no  attributes  of 
its  own. 


3.3. 1.2. 1.1.1  REAL 

The  nodes  in  class  REAL  --  float  and  fixed  --  represent  floating  point 
types  and  fixed  point  types,  respectively.  If  the  type  is  ot  a  generic  formal 
type  the  sm_accuracy  attribute  contains  the  value  of  the  accuracy  definition; 
digits  for  the  float  node,  and  delta  for  the  fixed  node.  The  value  of 
sm  accuracy  for  a  generic  formal  type  is  undefined.  The  fixed  node  defines  an 


DIANA  Reference  Manual  Draft  Revision  4 

SEMANTIC  SPECIFICATION 


Page  3-29 


additional  attribute,  cd  impl  small,  which  has  the  value  of  the  Ada  attribute 
SMALL. 


3.3. 1.2. 1.2  UNCONSTRAINED 

An  unconstrained  array,  record,  or  access  type  is  represented  by  a  node 
from  class  UNCONSTRAINED.  The  sm  base  type  attribute  of  an  array,  record,  or 
access  node  always  contains  a  self-reference.  The  sm  size  attribute  which  is 
defined  for  this  class  references  the  EXP  node  given  in  a  length  clause  for  that 
type;  if  no  such  clause  is  given  then  sm  size  is  void. 

The  access  node  represents  an  unconstrained  access  type.  An  access  type  is 
unconstrained  if  its  designated  type  is  an  unconstrained  array  type,  an 
unconstrained  record  type,  a  discriminated  private  type,  or  an  access  type 
having  a  designated  type  which  is  one  of  the  above;  otherwise,  it  is 
constrained.  A  derived  access  type  is  unconstrained  if  its  parent  subtype  is 
unconstrained  and  the  derived  type  definition  does  not  contain  an  explicit 
constraint. 

The  sm  desig  type  attribute  denotes  the  TYPE_SPEC  node  corresponding  to  the 
designated  type  --  an  incomplete  node,  or  a  node  from  class  UNCONSTRAINED  or 
class  PRIVATE_SPEC  (if  sm  desig  type  denotes  an  access  node,  then  the 
sm  desig  type  “attribute  57  that  access  node  cannot  refer  to  another  access 
node).  The  TYPE_SPEC  node  referenced  by  the  sm  desig  type  attribute  of  an 
access  node  is  never  anonymous. 

The  access  node  also  defines  the  attributes  sm  storage  size, 
sm  is  controlled,  and  sm  master.  The  sm  storage  size  attribute  denotes  the  EXP 
node  given  in  a  length  clause  if  one  is  applicable,  otherwise  it  is  void.  The 
attribute  sm  is  controlled  is  of  type  Boolean,  and  indicates  whether  or  not  a 
CONTROLLED  pragma  is  in  effect  for  that  type. 

The  attribute  sm  master  is  defined  only  for  those  access  types  having  a 
task  as  a  designated  subtype.  In  those  cases  it  references  the  master  which 
contains  the  corresponding  access  type  definition.  If  the  master  is  a  program 
unit  then  sm  master  denotes  the  declaration  of  the  unit  --  a  taslt_decl, 
subprog_entry_decl ,  or  package_decl  node.  If  the  master  is  a  block”  then 
sm  master  denotes  a  block_master  node,  which  contains  a  reference  to  the  block 
statement  containing  the  access  type  definition. 

The  array  and  access  nodes  may  represent  generic  formal  types,  in  which 
case  the  sm  size  attribute  is  void,  sm  storage  size  is  void,  sm  is  controlled  is 
false,  and  sm  is  packed  is  false. 


3. 3. 1.2. 1.2.1  UNCONSTRAI NED_C0MP0S I TE 

The  class  UNCONSTRAINED_COMPOSITE  represents  unconstrained  composite  types; 
it  is  composed  of  the  nodes  array  and  record.  Two  Boolean  attributes  are 
defined  on  this  class:  sm  is  limited  and  sm  is  packed.  The  attribute 
sm  is  limited  indicates  whether  or  not  the  type  has  any  subcomponents  which  are 
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of  a  limited  type;  sm  is  packed  records  the  presence  or  absence  of  a  PACK  pragma 
for  that  type. 

The  array  node  defines  two  attributes  of  its  own:  sm  index  s  and 
sm  comp  type.  The  sm  index  s  sequence  represents  the  index  subtypes  {undefined 
ranges)  of  the  Array'  The  attribute  sm  comp  type  references  a  TYPE_SPEC  node 
corresponding  to  the  component  subtype;  if  the  subtype  indication  representing 
the  component  subtype  imposes  a  new  constraint  then  this  TYPE_SPEC  node  is  an 
anonymous  subtype. 

The  node  record  defines  the  attributes  sm  discriminant  s.  sm  comp  list,  and 
sm  representation.  The  sm  discriminant  s  attribute  denotes  the  sequence  of 
discriminant  declarations  ref^erenced  by  the  as  dscrmt  decl  s  attribute  of  the 
type_decl  node  introducing  the  record  type;  this  sequence  may  be  empty.  The 
sm  comp  list  attribute  represents  the  component  list,  and  the  attribute 
sm  representation  designates  the  representation  clause  for  that  record  type;  if 
none  is  applicable  then  sm  representation  is  void. 


3. 3. 1.2. 1.3  CONSTRAINED 

A  constrained  array,  record,  or  access  type  is  represented  by  a  node  from 
class  CONSTRAINED,  The  class  CONSTRAINED  defines  the  boolean  attribute 
sm  depends  on  dscrmt,  which  is  true  for  a  record  component  subtype  which  depends 
on  a  discriminant,  and  false  in  all  other  cases.  The  sm  derived  attribute  for  a 
constrained_array  or  constra1ned_record  node  is  always  void. 

The  constrained_array  node  defines  an  sm  index  subtype  s  attribute  which 
denotes  a  sequence  that  does  not  correspond  to  source  code.  This  sequence  is  a 
semantic  representation  of  the  index  constraint,  and  is  derived  from  the 
as  discrete  range  s  sequence  of  the  index_constraint  node.  The 
sm  index  subtype  s  sequence  consists  of  integer  and/or  enumeration  nodes,  some 
of~  which  may  be  created  solely  for  this  sequence.  If  a  particular  discrete 
range  is  given  by  a  type  mark  then  a  new  node  is  not  created  to  represent  that 
discrete  range,  the  enumeration  or  integer  node  associated  with  the  type  mark  is 
used.  Otherwise,  a  new  enumeration  or  integer  node  is  created  to  represent  the 
new  anonymous  index  subtype. 

The  sm  base  type  attribute  of  a  constrained_array  node  always  denotes  an 
array  nodi’!  If  the  type  is  introduced  by  a  constrained  array  definition  then  an 
anoymous  base  type  is  created;  i.e.  the  sm  type  spec  attribute  of  the  type_id 
node  or  the  sm  obj  type  attribute  of  the  VC_NAME  node  denotes"  a 
constrained_array  ncde  which  has  an  anonymous  array  node  as  its  base  type.  If 
the  constrained  array  definition  is  part  of  an  object  declaration  then  the 
constrained__array  node  will  be  anonymous  as  well.  The  array  node  representing 
the  base  type  does  not  correspond  to  source  code;  its  sm  index  s  attribute  is  a 
sequence  of  undefined  ranges  which  also  are  not  derived  from  source  code.  The 
array  node  incorporates  the  information  in  the  constrained  array  type  definition 
pertaining  to  the  component  subtype,  and  the  constrained_array  node  retains  the 
constraint  information.  “ 
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A  constra1ned_record  node  has  an  sm  normalized  dscrmt  s  attribute  which  is 
a  normalized  sequence  of  the  expressions  given  in  the  discriminant  constraint. 
No  new  nodes  must  be  created  in  order  to  construct  this  sequence.  The 
sm  base  type  attribute  of  a  constrained  record  node  may  denote  a  node  of  type 
record,  private,  of  l_pr1vate. 

The  constrained_access  node  represents  a  constrained  access  type  or 
subtype.  Its  sm  desig  type  attribute  denotes  the  designated  subtype.  If  the 
constrained  access  node  is  introduced  by  either  a  type  declaration  in  which  the 
subtype  indication  contains  an  explicit  constraint,  or  a  subtype  declaration 
that  imposes  a  new  constraint,  then  the  designated  subtype  is  a  new  anonymous 
subtype.  The  sm  base  type  attribute  of  a  constrained  access  node  references  an 
access,  private,  or  Iprivate  node. 

The  constra1ned_array  and  constrained  access  nodes  may  represent  generic 
formal  types,  in  which  case  the  sm  depends~on  dscrmt  attribute  is  false. 
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Section  3.4 


TYPE  DEF 


3.4  TYPE_DEF 

The  nodes  in  class  TYPE_0EF  represent  the  following  constructs  in  the 
source  code: 

(a)  a  subtype  indication 

(b)  the  portion  of  a  type  declaration  following  the  reserved  word  "is" 

(c)  the  subtype  indication  or  constrained  array  definition  in  an  object 
declaration 

With  the  exception  of  the  nodes  constrained_array_def  and  subtype_ indication, 
the  nodes  in  this  class  may  be  designated  only  by  the  as  type  def  attribute  of 
the  type_decl  node. 

This  class  contains  numerous  nodes  which  do  not  define  attributes  of  their 
own,  their  purpose  being  to  differentiate  the  various  kinds  of  type  definitions. 
The  nodes  private_def  and  l_private_,def  correspond  to  private  and  limited 
private  type  definitions,”  respectively.  The  nodes  forma l_dscrt_def, 
formal_integer_def ,  formal  float_def,  and  formal_f ixed_def  correspond~to  generic 
formal”scalar  type  definitions. 

Th?  node  enum€ration_def  corresponds  to  an  enumeration  type  definition;  the 
attribute  as  enum  literal  s  denotes  a  sequence  corresponding  to  the  enumeration 
literals  given  in  t^he  definition. 

The  node  record_def  corresponds  to  a  record  type  definition;  as  comp  list 
is  the  component  list  given  in  the  definition. 


3.4.1  CONSTRAINED_DEF 

The  class  CONSTRAINED_DEF  consists  of  nodes  representing  source  code 
containing  a  constraint,  "hence  the  attribute  as  constraint  is  defined  on  this 
class. 

The  nodes  integer_def,  float_def,  and  fixed_def  correspond  to  numeric  type 
definitions;  the  as  constraint  "attribute  refirences  a  node  representing  the 
range  constraint,  floating  point  constraint,  or  fixed  point  constraint  given  in 
the  definition. 
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The  subtype_indication  node  records  the  occurrence  of  a  subtype  indication 
in  the  source  code.  It  is  never  designated  by  the  as  type  def  attribute  of  a 
type_decl  node;  however,  it  may  be  referenced  by  the  the  as  type  def  attribute 
of  an  OBJECT  OECL  node;  or  by  the  as  subtype  indication  attribute  of  a 
subtype_decl,  3iscrete_subtype,  subtype_a1 locator,  or  ARR_aCC_DER_OEF  node.  The 
as  constraint  attribute  denotes  the  constraint  given  in~the”subtype  indication 
(i?  there  is  no  constraint  then  this  attribute  is  void),  and  as  name  represents 
the  type  mark. 


3.4.2  ARR_ACC_0ER_0£F 

The  class  ARR_ACC_DER_OEF  is  composed  of  those  nodes  associated  with  type 
definitions  containing  ”a  subtype  indication;  in  particular,  array  type 
definitions,  access  type  definitions,  and  derived  type  definitions.  For  an 
array  definition  the  as  subtype  indication  attribute  denotes  a  node 
corresponding  to  the  component  subtype;  Tor  an  access  type  definition 
as  subtype  indication  is  the  designated  subtype;  for  a  derived  type  definition 
It  IS  the  parent  subtype. 

The  nodes  corresponding  to  array  definitions  each  have  an  additional 
attribute.  The  unconstrained_array_def  node  has  an  as  index  s  attribute  which 
denotes  a  sequence  representing  the  undefined  ranges  given  in  the  unconstrained 
array  definition.  A  constrained  array  definition  is  represented  by  the 
constrained_array_def  node,  which  has  an  as  constraint  attribute  corresponding 
to  the  sequence  of  discrete  ranges  given  iri  the  definition  (an  index  constraint 
node). 
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Section  3-5 


CONSTRAINT 


3.5  CONSTRAINT 

The  members  of  class  CONSTRAINT  represent  discrete  ranges  and  the  various 
kinds  of  constraints  defined  by  the  Ada  programming  language  (this  class  ’S  the 
union  of  the  Ada  syntactic  categories  "discrete_range"  and  "constraint").  This 
class  consists  of  the  nodes  index  constraint  and  dscrmt  constraint,  as  well  as 
the  classes  OISCRETE_RANGE  and  REAL^CONSTRAINT. 

The  node  index_constraint  represents  an  array  index  constraint.  The 
attribute  as  discrete  range  s  denotes  a  sequence  of  nodes  representing  the 
discrete  ranges. 

A  discriminant  constraint  is  represented  by  a  dscnnt_constraint  node.  The 
as  general  assoc  s  attribute  corresponds  to  the  sequence  of  discriminant 
associations  (a  sequence  of  nodes  of  type  named  and/or  EXP) . 


3.5.1  DISCRETE_RANGE 

The  class  DISCRETE  RANGE  contains  the  node  discrete  subtype  and  the  class 
RANGE . 

A  discrete  subtype  indication  is  represented  by  a  discrete_subtype  node. 
The  as  subtype  indication  attribute  references  a  node  representTng  the  subtype 
indication  itself. 


3.5.1. 1  RANGE 

The  nodes  which  comprise  class  RANGE  --  range,  range_attribute,  and  void  -- 
represent  ranges  and  range  constraints.  The  context  determines  whether  a  node 
belonging  to  class  RANGE  represents  a  range  or  a  range  constraint.  If  the  node 
is  introduced  by  an  as  constraint  attribute  then  it  represents  a  range 
constraint;  otherwise  it  is  simply  a  range. 

The  context  also  determines  the  value  of  the  sm  type  spec  atiribute.  For  a 
RANGE  node  introduced  by  a  subtype  indication  sm  type  spec  refers  to  the  SCALAR 
node  associated  with  the  type  mark.  If  the  RANGEnode  is  introduced  by  a  type 
definition  or  a  derived  type  definition  creating  a  new  scalar  type  then 
sm  type  spec  denotes  the  specification  cf  the  new  base  type.  Otherwise 
sm  type  spec  designates  the  node  correspond ing  to  the  appropriate  base  t^pe,  as 
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specified  by  the  Ada  Reference  Manual.  For  instance,  sm  base  type  of  a  RANGE 
node  corresponding  to  a  slice  denotes  the  specification  of  the  index  type. 

The  range  node  corresponds  to  a  range  given  by  two  simple  expressions, 
which  are  denoted  by  the  attributes  as  expl  (the  lower  bound)  and  as  exp2  (the 
upper  bound). 

The  range_attribute  node  represents  a  range  attribute.  The  as  name 
attribute  references  the  NAME  node  corresponding  to  the  prefix,  the  attribute 
as  used  name  id  designates  the  attr1bute_id  node  for  RANGE,  and  as  exp  denotes 
the  argument  specifying  the  desired  "dimension  (if  no  argt  -nt  is  given  tnen 

as  exp  is  void). 


3.5.2  REAL_CONSTRAINT 

The  class  REAL_CONSTRAINT  contains  the  nodes  f 1oat_constraint  and 
f ixed_Constraint,  representing  floating  point  constraints  and  fixed  point 
constraints,  respectively.  This  class  defines  two  structural  attributes: 
as  exp  and  as  range.  The  as  exp  attribute  references  the  node  representing  the 
simple  static  expression  for  digits  or  delta.  The  attribute  as  range  denotes 
the  range  given  in  the  constraint;  it  may  be  void  for  floating  point  constraints 
and  for  fixed  point  constraints  which  do  not  correspond  to  fixed  point  type 
definitions. 

The  nodes  belonging  to  REAL_CONSTRAINT  also  have  an  sm  type  spec  attribute. 
If  the  REAL_CONSTRAINT  node  corresponds  •  to  a  subtype  indication  then 
sm  type  spec  of”the  REAL_CONSTRAINT  node  and  the  corresponding  RANGE  node  (if 
there  is  one)  denotes  the  type  specification  associated  with  the  type  mark.  If 
the  constraint  is  introduced  by  a  real  type  definition  or  a  derived  type 
definition  then  sm  type  spec  of  the  REAL_CONSTRAINT  node  and  the  RANGE  ncce  (i* 
there  is  one)  references  the  type  specification  of  the  new  base  type. 


I 
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3.6. 1.1  RENAME_INSTANT 

The  nodes  in  class  RENAME_IMSTANT  Indicate  that  a  subprogram  or  a  package 
has  been  renamed  or  instantiated.  The  meaning  of  the  as  name  attribute  which  is 
defined  on  this  class  depends  on  whether  the  node  is  a  renames  unit  node  or  an 
instantiation  node. 


The  node  renaines_unit  represents  the  renaming  of  an  entity  as  a  subprogram 
or  a  package.  The  attribute  as  name  denotes  the  name  of  the  original  entity  as 
given  in  the  renaming  declaration.  The  valio  values  of  as  name  are  determined 
by  the  kind  of  entity  being  renamed;  they  are  as  follows: 


(a) 

package 

selected  or 

(b) 

procedure 

selected  or 

(c) 

function 

selected  or 

(d) 

operator 

selected  or 

(e) 

entry 

selected  or 

(f) 

enumeration  literal  - 

selected  or 

(g) 

attribute 

attribute 

used_naine_id 

used_name_id 

used_nanie_id 

used_op 

used_name_id  or  indexed 
used_char  or  used_object_id 


The  instantiation  node  signifies  the  instantiation  of  a  generic  subprogram 

or  package.  The  as  name  attribute  designates  a  used_name_id  or  selected  node, 

corresponding  to  the  name  of  the  generic  unit,  and”  the”  as  general  assoc  s 
attribute  denotes  a  possibly  empty  sequence  of  parameter  associations  (nooes  of 
type  EXP  and  assoc).  The  sm  deci  s  attribute  of  the  instantiation  ncce  's  a 
normalized  list  of  the  generic  parameters,  including  entries  for  all  default 
parameters. 

Declarative  nodes  are  used  to  represent  the  actual  parameters  in  the 

sm  decl  s  sequence.  Each  parameter  has  its  own  declarative  node,  ano  eacn 

declarative  node  introduces  a  new  SOURCE  NAME  node.  The  1 x  symrgp  attribute  of 
eacn  SOURCE_NAME  node  contains  the  symbd  representat ■’on  of  the  gere'^ic 
parameter;  however,  the  values  of  the  semant’c  attriputes  are  deterrrired  b>  the 
actual  parameter.  None  of  the  new  nodes  created  during  the  process  ot 

constructing  the  sm  decl  s  sequence  represent  source  code. 

The  declarations  are  constructed  as  follows: 

(a)  For  every  generic  forma’  in  parameter,  a  constant  declaration  is 
created.  The  as  source  name  s  sequence  of  the  constant_decl  node 

contains  a  single  constant_id  node.  The  as  type  def  attribute  is 
undefined,  and  the  as  exp  attribute  designates  either  the  actual 

expression  or  the  default  expression  of  the  generic  parameter 

declaration. 
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The  sin  first  attribute  of  the  constant_id  node  contains  a 
self-reference  (Tt  does  not  refer  to  the  in_i3  of  the  generic  formal 
object  declaration),  sm  renames  obj  is  false,  and  sm  obj  type  denotes 
the  TYPE  SPEC  node  of  the  actual  parameter  (or  default  expression). 
The  attriBute  sm  init  exp  designates  the  same  node  as  the  as  exp 
attribute  of  the  constant_dec1  node. 

(b)  For  every  generic  formal  in  out  parameter,  a  renaming  declaration  is 
created.  The  as  source  name  attribute  of  the  renaiiies_obj_decl  node 
denotes  a  new  variable_1d  node,  and  the  as  type  mark  name~attribute  is 
undefined.  The  as  name  attribute  designates  the  name  of  the  actual 
parameter  as  given  in  the  generic  actual  part. 

The  attribute  values  of  the  variable_id  are  determined  exactly  as 
if  the  declaration  were  a  genuine  renaming  of  the  actual  parameter  as 
the  formal  parameter  (see  section  3.2.2. 3.2. 1) . 

(c)  For  every  generic  formal  type  a  subtype  declaration  is  created.  The 

as  source  name  attribute  of  the  subtype_decl  node  designates  a  new 
subtype  id  node  which  has  an  sm  type  spec  attribute  denoting  the 
TYPE_SPEC  node  associated  with  the  actual  subtype.  The 
subtype_ indication  node  designated  by  the  as  subtype  indication 

attribute  has  a  void  as  constraint  attribute  and  an  as  name  attribute 
which  represents  the  type  mark  of  the  actual  subtype. 

(d)  For  every  generic  formal  subprogram,  a  new  subprogram  declaration  is 
created.  The  subprog_entry_decl  node  is  a  renaming  declaration, 
therefore  the  as  unit  kind  attribute  denotes  a  renames_unit  node  which 
references  either  the  actual  parameter  or  the  appropriate  default.  The 
as  header  attribute  denotes  the  HEADER  node  of  the  generic  actual 
parameter. 

The  as  source  name  attribute  designates  a  new  SUBPROG_NAME  or 
ENUM_LITERAL  node,  depending  on  the  actual  (or  deiault)  parameter.  The 
kind  of  node  and  the  values  of  its  attributes  (except  for  sm  spec)  are 
determined  precisely  as  if  the  declaration  were  an  explicit  renaming  of 
the  actual  entity  as  the  formal  subprogram  (see  sections  3. 1 . 1 . 3. 3. 2. 1 
and  3.2.2.4. 1 . 1 . 1) .  The  sm  spec  attribute  denotes  the  heade’"  of  the 
actual  oarameter  rather  than  that  of  the  generic  formal  caramete’" 
declaration. 


Once  the  normalized  declaration  list  is  constructed  the  specification  part 
of  the  generic  unit  is  copied;  however,  every  reference  to  a  formal  parameter  in 
the  original  generic  specification  is  changed  to  a  reference  to  the 
corresponding  newly  created  declaration.  In  addition,  all  references  to  the 
discriminants  of  a  formal  type  are  changed  to  denote  the  corresponding 
discriminants  of  the  newly  created  subtype  (i.e.  the  discriminants  of  the 
actual  type).  All  references  to  the  formal  parameters  of  a  formal  subprogram 
are  changed  to  denote  the  corresponding  parameters  of  the  newly  created 
subprogram  (i.e.  the  formal  parameters  of  the  actual  subprogram).  The  value  of 
the  as  name  attribute  of  a  DSCRMT_PARAM  DECL  node  is  undefined  in  this  copy  of 
the  specification,  as  is  the  value  of  the  as  type  def  attribute  of  ar. 
OBJECT  DECL  node. 


DIANA  Reference  Manual  Draft  Revision  4 
SEMANTIC  SPECIFICATION 


Page  3-42 


The  sm  spec  attribute  of  the  procedure_1d,  funct1on_1d,  or  package_id 
corresponding  to  the  instantiated  unit  designates  this  new  specification. 


3.6. 1.2  GENERIC_PARAM 

The  nodes  in  class  GENERIC_PARAM  are  used  to  indicate  that  a  subprogram  is 
a  generic  formal  parameter.  The  nodes  name_defau1t,  box_default,  and  no_defau1t 
comprise  GENERIC_PARAM. 

The  name  default  node  signifies  that  a  generic  formal  subprogram  has  an 
explicitly  gTven  default.  The  as  name  attribute  represents  the  name  of  the 
default  as  given  --  a  node  from  class  DESIGNATOR  or  an  indexed  node. 

The  node  box__default  indicates  that  a  box  rather  than  a  name  is  given  for 
the  default;  it  defines  no  attributes  of  its  own. 

The  no_default  node  records  the  fact  that  no  default  is  specified;  it 
defines  no  attributes  of  its  own. 


3.6.2  BODY 

The  class  BODY  represent  unit  bodies;  it  contains  the  nodes  stub, 
block_body,  and  void. 

The  stub  node  corresponds  to  a  body  stub;  it  defines  no  attributes  of  its 

own. 


The  block_body  node  repnesents  the  contents  of  either  a  proper  body  or  a 
block  statement.  It  has  three  structural  attributes  --  as  item  $,  as  stm  s,  and 
as  alternative  s  --  corresponding  to  the  declarative  part,  the  sequence  of 
statements,  and  the  exception  handlers,  respectively. 
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HEADER 


3.7  HEADER 

The  nodes  in  class  HEADER  contain  all  of  the  information  given  in  the 
specification  of  a  subprogram,  entry,  or  package  except  for  the  name  of  the 
entity.  HEADER  contains  the  node  package_spec  and  the  class  SUBP_ENTRY_HEADER. 

A  HEADER  node  corresponding  to  either  the  renaming  of  a  package  or  an 
instantiation  will  contain  no  information;  i.e.  any  sequence  attributes  will 
denote  empty  sequences  and  any  class-valued  attributes  will  be  void. 

The  node  package_spec  represents  the  declarative  parts  of  a  package 
specification.  It  has  two  semantic  attributes  --  as  decl  si  and  as  dec!  s2  -- 
corresponding  to  the  visible  and  private  parts  of  the  specification, 
respectively.  Either  or  both  of  these  sequences  may  be  empty. 


3.7.1  SUBP_ENTRY_HEADER 

The  nodes  in  class  SUBP_ENTRY_HEADER  record  the  information  given  in  the 
formal  part  of  a  subprogram  of  entry  declaration.  This  class  defines  an 
attribute  as  param  s  which  denotes  a  possibly  empty  sequence  of  parameter 
specifications.  The  nodes  procedure  spec,  function  spec,  and  entry  comprise 
SUBP_ENTRY_HEADER. 

The  node  function_spec  has  an  additional  attribute,  as  name,  representing 
the  type  mark  given”  in  the  function  specification.  If  the  function_spec 
corresponds  to  the  instantiation  of  a  generic  function  then  as  name  is  void; 
otherwise  U  designates  a  used_name_id  or  a  selected  node. 

The  entry  node  has  the  attribute  as  discrete  range,  denoting  the  discrete 
range  given  in  the  entry  declaration.  If  the  declaration  introduces  a  single 
entry  rather  than  an  entry  family  then  as  discrete  range  is  void. 
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3.8  GENERAL^ASSOC 

The  class  GENERAL_ASSOC  represents  the  following  kinds  of  associations: 


(a) 

parameter 

i 

(b) 

argument 

(c) 

generic 

V 

(d) 

component 

(e) 

discriminant 

The  classes  NAMED_ASSOC  and  EXP  comprise  GENERAL_ASSOC.  If  the  association 
is  given  in  named  form  then  it  is  represented  by  a  node  from  class  NAMED_ASSOC; 
otherwise  it  is  denoted  by  a  node  from  class  EXP. 


3.8.1  NAMED^ASSOC 

The  NAMED_ASSOC  class  contains  two  nodes  --  named  and  assoc.  It  defines  an 
attribute  as  exp  which  records  the  expression  given  in  the  association. 

The  assoc  node  corresponds  to  associations  which  contain  a  single  name; 
i.e.  parameter,  argument,  and  generic  associations.  The  as  used  name  attribute 
represents  the  argument  identifier  or  (generic)  formal  parameter  given  in  the 
associ ation. 

The  node  named  represents  associations  that  may  contain  more  than  one 
choice  --  component  associations  (of  an  aggregate)  and  discriminant  associations 
(of  a  discriminant  constraint).  It  defines  an  as  choice  s  attribute  which 
references  a  sequence  of  nodes  representing  the  choices  or  discriminant  names 
given  in  the  association.  The  simple  names  of  components  or  discriminants  that 
occur  within  associations  are  represented  by  used_name_id  nodes  rather  than 
used_object_id  nodes. 
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3.8.2  EXP 

The  EXP  class  represents  names  and  expressions;  its  three  components  are 

NAME,  EXP,  and  void. 

Certain  names  and  expressions  may  introduce  anonymous  subtypes;  i.e. 
slices,  aggregates,  string  literals,  and  allocators.  The  anonymous  subtype  is 
represented  by  a  constrained_array  or  a  constrained_record  node,  and  is 
designated  by  the  sm  exp  type  attribute  of  the  expression  introducing  it. 
Anonymous  index  subtypes  (for  an  anonymous  array  subtype)  are  introduced  by 
discrete  ranges  which  are  liOt  given  by  type  marks.  Subsequent  sections  will 
discuss  in  further  detail  the  circumstances  which  produce  an  anonymous  subtype, 
as  well  as  the  representation  of  the  subtype. 


3.8.2. I  NAME 

The  class  NAME  represents  used  occurrences  of  names;  it  contains  the 
classes  DESIGNATOR  and  NAME  EXP,  and  the  node  void. 


3.8. 2. 1.1  DESIGNATOR 

The  nodes  in  class  DESIGNATOR  correspond  to  used  occurrences  of  simple 
names,  character  literals,  and  operator  symbols.  DIANA  does  not  require  that 
each  used  occurrence  of  an  identifier  or  symbol  be  represented  by  a  distinct 
node  (although  it  does  allow  such  a  representation);  hence  it  is  possible  for  a 
single  instance  of  a  node  corresponding  to  a  used  occurrence  to  represent  all  of 
the  logical  occurrences  of  the  associated  identifier.  Used  occurrences  c'  'larrc; 
numbers  which  occur  in  certain  contexts  are  an  exception  to  the  previc-s 
statement;  see  section  3.8.2. 1.1.1. 

DESIGNATOR  consists  of  the  classes  USED  DBJECT  and  USED_NAME,  and  de^’ines 
the  attributes  sm  defn  and  lx  symrep.  The  sm  defn  attribute  references  the 
DEF_NAME  node  corresponding  to  the  defining  occurrence  of  the  entity  (if  the 
entity  is  predefined  the  DEF  NAME  node  is  not  accessable  through  structural 
attributes).  The  ’’x  symrep  att’"'^bute  ’s  t^e  string  '•eorese’^tat ^on  t''e 
of  the  entity. 


3.8.2. 1.1.1  USED_OBJECT 

The  class  USED_OBJECT  represents  appearances  of  enumeration  lite'^ais. 
objects,  and  named”  numbers.  The  sm  defn  attribute  of  a  node  from  this  class 
denotes  a  node  from  class  OBJECT_NAME. 

USED_DBJECT  defines  the  attributes  sm  exp  type  and  sm  value.  The 
sm  exp  type  attribute  denotes  the  subtype  of  the  entity;  i.e.  the  node 
designated  by  the  sm  obj  type  attribute  of  the  defining  occurrence  of  the 
entity.  The  sm  value  attribute  records  the  static  value  of  a  consian*.  scalar 
object;  if  the  entity  does  not  satisfy  these  conditions  then  sm  value  has  a 
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distinguished  value  indicating  that  it  is  not  evaluated. 

The  nodes  used  char  and  used_object_1d  constitute  this  class;  together  they 
represent  the  useH  occurrences  of  all  the  entities  having  defining  occurrences 
belonging  to  class  DBJECT_NAME.  The  used_char  node  represents  a  used  occurrence 
of  a  character  literal;”a  used_object_id  node  represents  the  use  of  an  object, 
an  enumeration  literal  denoted  by  an  identifier,  or  a  named  number.  The  sm  defn 
attribute  of  a  used_char  node  references  a  character  id,  the  sm  defn  attribute 
of  a  used_object_id  may  designate  any  node  from  class  0BJECT_NAME  except  for  a 
character~id. 

Although  the  names  of  objects  most  often  occur  in  expressions,  the  names  of 
certain  objects  --  those  of  record  components  (including  discriminants)  and 
parameters  --  may  also  occur  on  the  left-hand  side  of  named  associations;  these 
instances  are  represented  by  used_name_id  nodes  rather  than  used_object_id 
nodes. 

The  use  of  the  new  name  of  an  enumeration  literal  renamed  as  a  function 
represented  by  a  used_char  or  used_object_id  node  rather  than  a  function_cal 1 
node. 


If  a  used_object_id  corresponds  to  a  named  number,  and  the  use  represented 
by  the  used_object_id  occurs  in  a  context  requiring  an  implicit  type  conversion 
of  the  named~number7  then  the  sm  exp  type  attribute  of  the  used_object_id 
denotes  the  target  type  rather  than  a  universal  type.  This  means  that~it  is  not 
always  possible  for  a  single  used  occurrence  of  a  named  number  to  represent  all 
used  occurrences  of  that  named  number;  however,  a  single  used  occurrence  having 
a  particular  target  type  CAN  represent  all  used  occurrences  of  that  named  number 
requiring  that  particular  target  type. 


3. 8. 2. 1.1.2  USED_NAME 

The  class  USED_NAME  represents  used  occurrences  of  identifiers  or  symbols 
corresponding  to  entities  which  do  not  have  a  value  and  a  type.  It  contains  the 
node  used_op  and  used_name_id. 

The  node  used_op  -eoresents  the  use  of  an  operator  symbol,  he''.;e  its 
sm  de^n  attr’bute  denotes  either  an  operator_id  O’"  a  bltn_operator_id. 

A  used_naine_id  node  represents  a  use  of  the  name  of  any  of  the  remaining 
kinds  of  intitTes.  It  may  also  record  the  occurrence  of  the  simple  name  of  a 
discriminant,  a  component,  or  a  parameter  on  the  left-hand  side  of  a  named 
association  (however,  it  does  not  denote  a  used  occurrence  of  such  an  object  in 
any  other  content).  Excluding  th's  special  case,  sm  defn  may  rei'e-ence  ary 
member  of  class  DEF_NAME  except  for  an  operator_id,  a  bltn_operator  id,  or  a 
member  of  class  OBJECT~NAME. 
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3.8.2. 1.2  NAMEJXP 

The  nodes  in  class  MAME_EXP  represent  names  which  are  not  simple 
identifiers  or  character  symbols;  i.e.  function  calls  and  names  having  a 
prefix.  The  attributes  as  name  and  sm  exp  type  are  defined  for  the  nodes  in 
this  class.  The  as  name  attribute  represents  either  the  name  of  the  function  or 
the  prefix. 

If  the  NAME__EXP  node  corresponds  to  an  expression  then  sm  exp  type 
corresponds  to  tHe  subtype  of  the  entity,  otherwise  it  is  void"!  Theo^ 
NAME_EXP  nodes  which  can  possibly  have  a  void  sm  exp  type  attribute  are  the 

indexed,  attribute,  and  selected  nodes. 

The  node  all  represents  a  dereferencing;  i.e.  a  selected  component  formea 
with  the  selector  "all".  The  as  name  attribute  corresponds  to  the  access 
object,  and  sm  exp  type  is  the  designated  subtype. 

The  indexed  node  represents  either  an  indexed  component  or  a  reference  tc  a 
member  of  an  entry  family.  For  an  indexed  component  the  as  exp  s  attribute 
denotes  a  sequence  of  index  expressions,  as  name  is  the  array  prefix,  and 
sm  exp  type  is  the  component  subtype.  The  as  exp  s  attribute  of  an  entry  family 
member  is  a  one-element  sequence  containing  the  entry  index;  as  name  is  t^e 
entry  name,  and  sm  exp  type  is  void. 

A  slice  is  represented  by  a  slice  node.  The  as  name  attribute  denotes  the 
array  prefix  and  the  as  discrete  range  attribute  is  the  discrete  range. 

The  sm  exp  type  attribute  denotes  the  subtype  of  the  slice.  The  subtype  of 
a  slice  is  anonymous  unless  it  can  be  determined  statically  that  the  bounds  of 
the  slice  are  identical  to  the  bounds  of  the  array  prefix,  in  which  case  tne 
sm  exp  type  attribute  of  the  slice  node  is  permitted  to  reference  tne 
constrained_array  node  associated  with  the  array  prefix.  Otner«ise,  an 
anonymous  subtype  is  created  for  the  slice  node.  The  anonymous  subtype  is 
represented  by  a  constrained_array  node  having  the  same  base  type  as  that  of  tne 
array  prefix;  however,  the  constraint  is  taken  from  the  discrete  range  giver  in 
the  slice. 


3. 8. 2. 1.2.1  NAME_VAL 

The  class  NAME_\/AL  contains  NAME_EXP  nodes  which  may  have  a  static  value, 
consequently  the  sm  value  attribute  Is  defined  for  the  nodes  in  this  class.  If 
the  value  is  not  static,  sm  value  has  a  distinguished  value  indicating  that  the 
expression  is  not  evaluated.  NSME_VAL  comprises  the  nodes  attribute,  selected, 
and  function_cal 1 .  ~ 

The  node  attribute  corresponds  to  an  Ada  attribute  othe«-  than  a  RANGE 
attribute  (which  is  represented  by  a  range_attribute  node).  The  DIANA  attribute 
as  name  denotes  the  prefix,  as  used  name  references  the  attribute  id 
corresponding  to  the  given  attribute  name,  and  as  exp  is  the  universal  static 
expression.  If  no  universal  expression  is  present  then  as  exp  is  void. 
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The  value  of  the  stn  exp  t>pe  attribute  of  an  attribute  node  depends  on  the 
kind  of  Ada  attribute  it  represents,  as  well  as  the  context  in  which  it  occurs. 
If  the  attribute  node  represents  the  BASE  attribute  then  siti  exp  type  is  void. 
If  the  Ada  attribute  returns  a  value  of  a  universal  type,  and  that  value  is  the 
object  of  an  implicit  type  conversion  (determined  by  the  context),  then 
sffl  exp  type  references  the  target  type.  Otherwise  sm  exp  type  denotes  the 
TYPE  SPEC  node  corresponding  to  the  type  of  the  attribute  as  specified  in  the 
Ada  l^eference  Manual. 

The  node  selected  represents  a  selected  component  formed  with  any  selector 
other  than  the  reserved  word  "all"  (this  includes  an  expanded  name).  The 
as  name  attribute  denotes  the  prefix,  and  as  designator  corresponds  to  the 
seTector.  If  the  selected  node  represents  anobject  (i.e.  an  entity  having  a 
value  and  a  type,  for  instance  a  record  component)  then  sm  exp  type  is  the 
subtype  of  the  object;  otherwise  it  is  void. 

All  function  calls  and  operators  are  represented  by  function_cal 1  nodes, 
with  the  exception  of  the  short  circuit  operators  and  the  membership  operators. 
The  as  name  attribute  denotes  the  name  of  the  function  or  operator  --  a 
used_naine_id,  used_op,  or  selected  node.  The  lx  prefix  attribute  records 
whether  the  function  call  is  given  using  infix  or  pr^ifix  notation.  The 
as  general  assoc  s  attribute  is  a  possibly  empty  sequence  of  paramete’' 
associations  (nodes  of  type  EXP  and  assoc);  sm  normalized  pa'^am  s  is  a 
normalized  list  of  actual  parameters,  including  any  expressions  for  default 
parameters.  The  sm  exp  type  attribute  denotes  the  return  type.  If  the  function 
call  corresponds  to  a  predefi'^.d  operator  then  sm  exp  type  references  the 
appropriate  base  type,  as  specified  in  section  4,5  of  the  Ada  Reference  Manual. 

Although  the  use  of  an  enumeration  literal  is  considered  to  be  equiva'ient 
to  a  parameterless  function  call,  it  is  represented  by  a  used_char  or 
used_object_id  node  rather  tnan  a  function_cal 1  node  (this  includes  the”  use  of 
an  enumeration  literal  renamed  as  a  function).  However,  the  use  of  an  attribute 
renamed  as  a  function  is  represented  by  a  function_can  node,  not  an  attribute 
node. 


3. 8. 2. 2  EXPEXP 

The  class  EXP_EXP  renvos  ents  e'<oress  ons  wh’ch  a’'®  not  namPS.  "^0“ 
attribute  sm  exp  type  which  is  defined  on  this  class  denotes  the  TYPt_SPtC  noce 
corresponding  to  the  subtype  of  the  expression.  EXP_EXP  contains  the  nodes 
qualified  allocator  and  subtype  allocator  as  well  as  the  classes  AGG  EXP  and 
EXP_VAL. 

The  nodes  qualified_allocator  and  subtype  allocator  reoresent  the  two  forms 
of  allocators.  Each”  node  has  the  appropriate  structural  attribute  -- 
as  qual i f ied  or  as  subtype  indication  --  to  retain  the  information  given  in  the 
allocator.  The  sm  exp  type  attribute  denotes  the  TYPE_SPEC  node  corresponding 
to  the  subtype  of  the  access  value  to  be  returned,  as  determined  from  the 
context.  The  subtype_al locator  defines  an  additional  attribute,  sm  desig  type, 
which  denotes  a  TYPE_SPEC  node  corresponding  to  the  subtype  of  the  object 
created  by  the  allocator.  If  the  subtype  ind'cation  cc'fa'ns  an  e''o''cit 
constraint  then  sm  desig  type  denotes  a  new  TYPE_SPEC  node  corresponding  to  the 
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anonymous  subtype  of  the  object  created  by  the  allocator. 


3. 8. 2. 2.1  AGG_EXP 

The  AGG_EXP  class  represents  aggregates  and  string  literals;  it  is  composed 
of  the  nodes  aggregate  and  string_1itera1.  The  aggregate  node  may  represent  an 
aggregate  or  a  subaggregate.  The  str1ng_litera1  node  represents  a  string 
literal  (which  may  also  be  a  subaggregate  if  it  corresponds  to  the  last 
dimension  of  an  aggregate  corresponding  to  a  multidimensional  array 
characters) • 

The  class  AGG_EXP  defines  an  sm  discrete  range  attribute  to  represent  the 
bounds  of  a  subaggregate;  sm  discrete  rangeis  void  for  a  node  representing  an 
aggregate.  The  sm  exp  type  attribute  of  a  node  corresponding  to  an  aggregate 
denotes  the  subtype  of  the  aggregate;  it  is  void  for  a  subaggregate.  This 
implies  that  in  an  aggregate  or  str1ng_1 iteral  node  exactly  one  of  these  two 
attributes  is  void. 

If  sm  exp  type  is  not  void,  it  designates  a  constrained_array  or 
constrained_record  node  corresponding  to  tne  subtype.  An  aggregate  or  a  str^’^g 
literal  has~an  anonymous  subtype  unless  it  can  be  determined  statically  that  tne 
constraints  on  the  aggregate  are  identical  to  those  of  the  subtype  obtained  from 
the  context,  in  which  case  sm  exp  type  may  (but  does  not  have  to)  reference  the 
node  associated  with  that  subtype. 

If  the  aggregate  has  an  anonymous  subtype  it  is  constructed  from  the  base 
type  of  the  context  type  and  the  bounds  as  determined  by  the  ru'es  in  the  Ada 
Reference  Manual.  If  the  bounds  on  the  subaggregates  for  a  particular  dimension 
of  a  multidimensional  aggregate  are  not  the  same  (a  situation  which  v.ill  result 
in  a  CONSTRAINT  ERROR  during  execution)  DIANA  does  not  specify  the  ^utagg'^egate 
from  which  the  bounds  for  the  index  constraint  are  taken. 

The  string_l iteral  node  defines  only  one  additional  attribute,  ;x  symrep, 
which  contains  the  string  itself. 

The  aggregate  node  has  two  different  representations  of  the  seauence  oi" 
component  associations;  both  may  contain  nodes  of  type  named  arc  EXP.  I'ne 
as  genera!  assoc  s  attribute  denotes  the  sequence  of  comocnent  isscc -'at  ^cns  as 
givenl  smnormaTTzed  comp  s  is  a  sequence  of  normalized  component  associations 
which  are  not  necessarily  in  the  same  form  as  given,  for  the  following  reasons; 

(a)  Each  named  association  having  multiple  choices  is  decomposed  into 
separate  associations  for  the  sm_normal ized_comp_s  sequence,  one  for 
each  choice  in  the  given  association;  hence  the  as  choice  $  sequence  c' 
a  named  node  in  the  normalized  list  contains  only  one  element.  The 
manner  in  which  this  decomposition  is  done  is  not  specified,  the  only 
requirements  being  that  the  resulting  associations  be  equivalent,  and 
that  each  association  be  either  the  component  expression  itself  or  a 
named  association  with  only  one  choice.  Consider  the  array  aggregate 


(  1  1  2  I  3  =>  10  ) 
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The  named  association  could  be  broken  down  in  such  a  way  that  the 
sm  normal i zed  comp  s  sequence  appeared  as  if  it  came  from  any  of  the 
following  aggregates: 

(  1  =>  10.  2  =>  10.  3  =>  10  ) 

(  1..3  =>  10  ) 

(  10.  10.  10  ) 


In  the  process  of  normalizing  the  component  associations  new  named 
nodes  may  be  created,  and  duplication  of  the  component  expressions  is 
optional.  For  the  remainder  of  this  section  all  named  component 
associations  will  be  treated  as  if  they  had  only  one  choice. 

(b)  For  a  record  aggregate,  if  a  choice  is  given  by  a  component  name  then 

the  component  expression  rather  than  the  named  node  is  inserted  in  the 
proper  place  in  the  sequence,  hence  the  normalized  sequence  for  a 

record  aggregate  is  actually  a  sequence  of  EXP  nodes. 

(c)  In  an  array  aggregate  an  association  containing  a  choice  which  is  a 

simple  expression  may  be  replaced  by  the  component  expression  if  it  can 

be  determined  statically  that  the  choice  belongs  to  the  appropriate 
index  subtype  (this  substitution  is  optional). 

(d)  A  named  association  with  an  "others"  choice  is  not  allowed  in  the 

sm  normalized  comp  s  sequence.  For  each  component  or  range  of 
components  denoted  by  the  "others"  either  a  component  expression  is 
inserted  in  the  proper  spot  in  the  sequence,  or  a  new  named  node  is 
created  containing  the  appropriate  range. 


Due  to  some  of  the  changes  mentioned  above  it  is  possible  for  the 
sm  normalized  comp  s  sequence  of  an  array  aggregate  to  contain  a  mixture  of  EXP 
and  named  nodes. 


3. 8. 2. 2. 2  EXP_VAL 

The  EXP_VAL  class  contains  nodes  representing  expressions  which  may  have 
static  values,  hence  the  sm  value  attribute  is  defined  for  the  nodes  in  this 
class.  If  the  value  is  not  static  then  sm  value  has  a  distinguished  value  which 
indicates  that  the  expression  is  not  evaluated. 

A  numeric  literal  is  represented  by  a  numeric_l Iteral  node.  It  has  an 
attribute  lx  numrep  containing  the  numeric  representation  of  the  literal.  If 
the  literal  is  the  object  of  an  implicit  conversion  then  sm  exp  type  denotes  the 
target  type  rather  than  a  universal  type. 

The  null  access  node  corresponds  to  the  access  value  NULL;  it  defines  no 
attributes  o7  its  own.  Although  a  distinct  null  access  node  may  be  created  for 
each  occurrence  of  the  access  value  NULL,  DIANA  also  permits  a  single 
null  access  node  to  represent  all  occurrences  of  the  literal  NULL  for  tnat 
particular  access  type. 
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The  node  short_circu1t  represents  the  use  of  a  short  circuit  operator.  The 
as  short  circuit  op~  attribute  denotes  the  operator  {and_then  or  or_else); 
as  expl  and  as  ex^  represent  the  expressions  to  the  left  "and  right  of  the 
operator,  respectively. 


3. 8. 2. 2. 2.1  EXP_VAL_EXP 

The  class  EXP_VAL_EXP  defines  an  as  exp  attribute;  it  comprises  the  node 
parenthesized  and  the  classes  MEMBERSHIP  and  QUAL_C0NV. 

The  parenthesized  node  represents  a  pair  of  parentheses  enclosing  an 
expression.  The  as  exp  attribute  denotes  the  enclosed  expression,  sm  value  is 
the  value  of  the  expression  if  it  is  static,  and  sm  exp  type  is  the  subtype  of 
the  expression.  A  parenthesized  node  can  nEvER  be  denoted  by  a  semantic 
attribute,  nor  can  it  be  included  directly  in  a  sequence  that  is  constructed 
exclusively  for  a  semantic  attribute  (such  as  a  normalized  sequence);  the  node 
representing  the  actual  expression  is  referenced  instead. 


3. 8. 2. 2. 2. 1.1  MEMBERSHIP 

The  class  MEMBERSHIP  represents  the  use  of  a  membership  operator.  The 
attribute  as  exp  records  the  simple  expression,  and  the  as  membership  attribute 
denotes  the  applicable  membership  operator  (1n_op  or  not_in) .  MEMBERSHIP 
contains  two  nodes:  range^^membership  and  type^iilembership.  "Each  contains  the 
appropriate  structural  attribute  to  retain  the  type  or  range  given  in  the 
expression. 


3. 8. 2. 2. 2. 1.2  QUAL_C0NV 

The  nodes  in  class  QUAL_C0NV  --  qualified  and  conversion  --  correspond  to 
qualified  expressions  and  "explicit  conversions,  respectively.  The  as  exp 
attribute  denotes  the  given  expression  or  aggregate,  and  as  name  references  the 
node  associated  with  the  type  mark.  The  sm  exp  type  attribute  denotes  tne 
TYPE  SPEC  node  corresponding  to  the  type  mark. 
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Section  3.9 


STMJLEM 


3.9  STMJLEM 

The  class  STM_ELEM  contains  nodes  representing  items  which  may  appear  in  a 
sequence  of  statements;  i.e.  nodes  corresponding  to  statements  or  pragmas. 

The  node  stm^pragma  represents  a  pragma  which  appears  in  a  sequence  of 
statements.  Its”  only  non-lexical  attribute,  as  pragma,  designates  a  pragma 
node. 


3.9.1  STM 

A  node  from  class  STM  represents  an  Ada  statement.  Some  of  the  STM  nodes 
are  grouped  together  because  they  are  similar  in  their  structure  to  other  nodes 
in  the  class;  the  manner  in  which  these  nodes  are  classified  does  not  imply  any 
semantic  similarity. 

The  node  nul1_stm  represents  a  NULL  statement;  it  defines  no  attributes  of 
its  own.  “  ' 

The  node  labeled  represents  a  labeled  statement.  The  as  source  name  s 
attribute  denotes  a  sequence  of  label  names  (label^id  nodes).  These  label  names 
are  defining  occurrences,  hence  the  labeled  node  serves  as  a  "declaration"  for 
the  associated  labels.  The  as  pragma  s  attribute  represents  the  pragmas 
occurring  between  the  label(s)  and  the  statement  itself;  it  designates  a 
possibly  empty  sequence  of  pragma  nodes.  The  as  stm  attribute  denotes  the 
actual  statement,  it  may  reference  any  type  of  STM  node  other  than  another 
labeled  node. 

The  accept  node  represents  an  accept  statement.  The  as  name  attribute 
records  the  entry  simple  name;  it  may  denote  either  a  used_name_id  or  an  indexed 
node,  depending  on  whether  or  not  the  entry  is  a  member  of~an  entry  family.  The 
attr'.jte  as  param  s  denotes  a  possibly  empty  sequence  of  nodes  from  class  PARAM 
corresponding  to  the  formal  part.  The  as  stm  s  attribute  is  a  possibly  empty 
sequence  representing  the  statements  to  be  executed  during  a  rendezvous. 

The  abort  node  represents  an  abort  statement.  The  as  name  s  attribute  is  a 
sequence  of  nodes  corresponding  to  the  task  names  given  in  the  abort  statement. 

The  node  terminate  corresponds  to  a  terminate  statement;  it  defines  no 
attributes  of  its  own. 
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The  node  goto  represents  a  goto  statement.  The  as  name  attribute 
corresponds  to  the  label  name  given  in  the  statement. 

The  raise  node  represents  a  raise  statement.  The  attribute  as  name  denotes 
the  exception  name,  if  specified;  otherwise  it  ^s  void. 


3. 9. 1.5.1  CALL_STM 

The  class  CALL_STM  represents  procedure  calls  and  entry  calls;  it  comprises 
the  nodes  procedufe__cal  1  and  entry_can.  CALL_STM  defines  two  attributes: 
as  general  assoc  s  and  sm  normalized  param  s.  The  attribute  as  general  assoc  s 
denotes  a  possibly  empty  sequence  containing  a  mixture  of  assoc  and  £5{P  nodes 
representing  the  parameter  associations.  The  sm  normalized  param  s  attribute 
designates  a  possibly  empty  sequence  corresponding  to  a  normalized  list  of 
actual  parameters. 

A  call  to  an  entry  that  has  been  renamed  as  a  procedure  is  represented  by  a 
procedure_cal1  node  rather  than  an  entry_call  node. 


Section  3.10 


MISCELLANEOUS  NODES  AND  CLASSES 


3.10  MISCELLANEOUS  NODES  AND  CLASSES 
3.10.1  CHOICE 

A  node  from  class  CHOICE  represents  either  the  use  of  a  discriminant  simple 
name  in  a  discriminant  association,  or  a  choice  contained  in  one  of  the 
following; 

(a)  a  record  variant 

(b)  a  component  association  of  an  aggregate 

(c)  a  case  statement  alternative 

(d)  an  exception  handler 

Nodes  in  this  class  may  appear  only  as  a  part  of  a  sequence  of  choice  nodes. 
CHOICE  comprises  the  nodes  choice_exp,  choice_range,  and  choice_others. 

The  node  choice_exp  represents  a  choice  that  is  a  simple  name  or  an 
expression;  it  has”a  single  structural  attribute  --  as  exp.  If  the  choice_exp 
node  corresponds  to  a  simple  name  (that  of  a  discriminant,  a  component,  or”  an 
exception)  then  as  exp  references  a  used__name_id  node.  Otherwise,  choice__exp 
must  represent  a  choice  consisting  of  a  simple  expression,  which  is  represented 
by  a  node  from  class  EXP. 

A  choice  which  is  a  discrete  range  is  represented  by  a  choice_range  node. 
The  as  discrete  range  attribute  references  the  discrete  range. 

A  choice_others  node  corresponds  to  the  choice  "others";  it  defines  no 
attributes  of'its  own. 


3.10.2  ITERATION 

The  members  of  class  ITERATION  --  while,  F0R_REV,  and  void  --  represent  the 
iteration  schemes  of  a  loop  (void  corresponds”to  the  absence  of  an  iteration 
scheme).  These  nodes  are  introduced  by  the  as  iteration  attribute  of  a  loop 
node. 
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The  while  node  represents  a  “while"  iteration  scheme.  The  as  exp  attribute 
denotes  a  node  representing  the  given  condition. 


3.10.2.1  F0R_REV 

The  F0R_REV  class  represents  a  "for"  iteration  scheme.  If  the  reserved 
word  "reversi"  appears  in  the  loop  parameter  specification  then  the  iteration  is 
represented  by  a  reverse  node;  otherwise  it  is  denoted  by  a  for  node.  The 
as  source  name  attribute  designates  an  iteration_id  corresponding  to  the 
defining  occurrence  of  the  loop  parameter.  The  as  discrete  range  attribute 
represents  the  discrete  range. 


3.10.3  MEMBERSHIP^OP 

The  class  MEMBERSHIP_0P  consists  of  the  nodes  in_op  and  notin.  These 
nodes  are  introduced  by  the  as  membership  op  attribute  of  a  MEMBERSHIP  node, 
their  function  being  to  indicate  "which  operator  is  applicable. 


3.10,4  SHORT_CIRCUIT_OP 

The  nodes  in  class  SHORT_CIRCUIT  OP  --  and__then  and  or_else  --  serve  to 
distinguish  the  two  types  of”short- cTrcuit  expressions.  They  are  introduced  by 
the  as  short  circuit  op  attribute  of  the  short_circuit  node. 


3.10.5  ALIGNMENT_CLAUSE 

The  class  ALIGNMENT_CLAUSE  represents  the  alignment  clause  portion  of  a 
record  representation  clause.  It  is  composed  of  the  nodes  alignment  and  void 
(void  corresponds  to  the  absence  of  an  alignment  clause). 

The  alignment  node  contains  the  attributes  as  pragma  s  and  as  e>p.  The 
former  is  a  possibly  empty  sequence  of  pragma  nodes  corresponding  to  the  oragm^s 
occurring  between  the  reserved  word  "record"  and  the  alignment  clause.  The 
as  exp  attribute  refers  to  the  node  associated  with  the  static  simple 
expression. 


3.10.6  VARIANT_PART 

The  VARIANT_PART  class  represents  the  variant  part  of  a  record  type 
definition;  it  contains  the  nodes  variant_part  and  void  (void  corresponds  to  the 
absence  of  a  variant  part). 
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The  var1ant_part  node  defines  the  attributes  as  name  and  as  variant  s.  The 
as  nyie  attribute  references  a  used_object  Id  corresponding  to  the  discriminant 
simple  name;  as  variant  s  is  a  sequence  containing  at  least  one  variant  node  and 
possibly  var1ant_pragiia  nodes. 


3.10.7  TEST_CLAUSE_ELEM 

The  class  TEST_CLAUSE_ELEM  represents  alternatives  for  an  if  statement  or  a 
selective  wait  statement.”  It  contains  the  node  se1ect_alt_pragma  and  the  class 
TEST_CLAUSE.  These  nodes  may  appear  only  in  a  test_clause_ile«_s  sequence. 

The  node  select_alt_pragnia  represents  a  pragma  which  occurs  at  a  place 
where  a  select  "alternative  is  allowed.  It  may  appear  only  in  a 
test_clause_e1em_s  sequence  of  a  select1ve_wa1t  node.  The  as  pragma  attribute 
denotes  the”pragma  itself. 


3.10.7.1  TEST_CLAUSE 

A  TEST__CLAUSE  node  (cond_clause  or  select_a1ternative)  represents  a 
condition  and  sequence  of  statements  occurring  in  an  if  statement  or  a  selective 
wait  statement.  The  as  exp  attribute  corresponds  to  the  condition,  and  the 
as  stm  s  attribute  to  the  sequence  of  statements.  The  cond_clause  node  may 
appear  only  in  a  test_clause_elem^s  sequence  of  an  If  node,  and  the 
select  alternative  node  ”may  occur  "only  in  a  test_clause_elem_s  sequence  of  a 
selectTve  wait  node. 


3.10.8  ALTERNATIVE_ELEM 

The  class  ALTERNATIVE_ELEM  represents  case  statement  alternatives, 
exception  handlers,  and  pragmas  which  occur  at  a  place  where  either  of  the 
previous  items  are  allowed.  The  nodes  alternative  and  a1ternative_pragma 
constitute  ALTERNATIVE_ELEM;  they  may  occur  only  as  members  of  a1ternative_s 
sequences. 

The  alternative_pragma  node  has  a  single  structural  attribute,  as  pragma, 
which  denotes  the  pragma. 

The  alternative  node  contains  two  non-lexical  attributes;  as  choice  s  and 
as  stm  s.  For  a  case  statement  alternative  the  as  choice  s  sequence  may  contain 
any  of  the  nodes  belonging  to  class  CHOICE;  however,  for  an  exception  handler 
the  sequence  is  restricted  to  containing  choice_exp  and  choice_others  nodes. 
The  as  stm  s  attribute  represents  the  sequence  of  statements  given  in  the 
alternative  or  handler. 
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3.10.9  COMP_REP_ELEM 

The  class  COMP  REP_ELEM  consists  of  the  nodes  co«4)_rep  and  coiiip_rep_pragma , 
which  may  appear  only  in  the  as  comp  rep  s  sequence  of  a  record_rep  node7 

The  comp  rep  node  represents  a  component  representation  clause.  The 
as  name  attribute  references  a  used  object_id  corresponding  to  the  component 
simple  name,  as  exp  represents  the  static  simple  expression,  and  as  range 
denotes  the  static  range. 

A  pragma  that  occurs  at  the  place  of  a  component  clause  is  represented  by  a 
co«p_rep_pragna  node;  as  pragma  denotes  the  pragma. 


3.10.10  C0NTEXT_ELEM 

The  nodes  in  class  C0NTEXT_ELEM  represent  items  which  may  appear  at  a  place 
where  a  context  clause  is  allowed.  They  may  occur  only  as  members  of  the 
context_eleiii_s  sequence  of  a  coinpi1ation_unit  node. 

The  with  node  represents  a  with  clause  and  any  subsequent  use  clauses  and 
pragmas.  The  as  name  s  attribute  is  a  sequence  of  used_name_id  noaes 
corresponding  to  the  1 ibrary  unit  names  given  in  the  with"  clause.  The 
as  use  pragma  s  attribute  is  a  possibly  empty  sequence  which  can  contain  nodes 
of  type  use  and  pragma. 

The  context^pragraa  node  has  a  single  non-lexical  attribute,  as  pragma, 
which  denotes  the  pragma. 


3.10.11  VARIANTJLEM 

The  nodes  in  class  VARIANT  ELEM  correspond  to  items  which  may  appear  at  a 
spot  where  a  variant  is  allowed.  These  nodes  are  contained  in  the  sequence 
denoted  by  the  as  variant  s  attribute  of  the  variant_part  node. 

The  variant  node  has  two  structural  attributes:  as  chci-e  s  and 
as  comp  list.  The  as  choice  s  attribute  is  a  sequence  represencinq  the  choices 
applicable  to  that  particular  variant;  as  comp  list  corresponos  to  tne  componeni 
list. 


The  sole  non-lexical  attribute  of  the  variant_pragma  node  is  as  pragma, 
denoting  the  pragma. 


3.10.12  compilation 

The  node  compilation  corresponds  to  a  compilation;  it  defines  the  attribute 
as  compltn  unit  s,  a  possibly  empty  sequence  of  compilation_unit  nodes. 


DIANA  Reference  Manual  Draft  Revision  4 
SEMANTIC  SPECIFICATION 


Page  3-65 


3.10.13  coii4)i1ation_unit 

A  cofflp11ation_un1t  node  represents  an  item  or  items  which  may  appear  at  a 
place  where  a  compilation  unit  is  allowed;  i.e.  it  may  represent  a  compilatior 
or  a  sequence  of  pragmas. 

A  coinpi1at1on_unit  node  represents  a  sequence  of  pragmas  only  when  a 
compilation  consists  of  pragmas  alone.  In  this  case  the  as  context  e1em  s 
sequence  is  empty,  the  as  all  decl  attribute  is  void,  and  as  pragma  s  denotes 
the  sequence  of  pragmas  which  constitute  the  compilation. 

For  a  compilation  unit  node  correspondin'  to  a  compilation  unit  the 
as  context  elem  s  attribute  is  a  possibly  empty  sequence  representing  the 
context  clause  and  any  pragmas  preceding  the  compilation  unit.  The  as  aH  ded 
attribute  denotes  the  library  unit  or  the  secondary  unit,  which  may  be 
represented  by  one  of  the  following:  a  node  belonging  to  class  UNIT_DECL,  a 
subunit,  a  subprograin_body ,  or  a  paclcage_body.  The  as  pragma  s  attribute 
denotes  the  pragmas  which  follow  the  compilation  unit  and  do  not  belong  to  a 
subsequent  compilation  unit.  The  pragmas  allowed  to  appear  in  this  sequence 
include  INLINE,  INTERFACE,  LIST,  and  PAGE.  LIST  ano  PAGE  pragmas  which  occur 
between  compilation  units  but  after  any  INLINE  or  INTERFACE  pragmas  may  appear 
in  either  the  as  pragma  s  sequence  of  tne  preceding  compilation  unit  or  the 
as  context  elem  s  sequence  of  the  succeeding  compilation  unit. 


3.10.14  comp_list 

A  record  component  list  is  represented  by  a  comp_list  node,  which  contains 
three  structural  attributes:  as  decl  s,  as  variant  part,  and  as  pragma  s.  The 
as  decl  s  attribute  designates  a  sequence  corresponding  to  either  a  series  of 
component  declarations  or  the  reserved  word  "null".  The  attribute 
as  variant  part  denotes  the  variant  part  of  the  record,  if  one  exists.  The 
as  pragma  s  attribute  records  the  occurrence  of  pragmas  between  the  variant  part 
and  the  end  of  the  record  declaration  (i.e.  pragmas  appearing  between  "end 
case"  and  "end  record"). 

If  the  record  is  a  null  record  then  as  variant  part  is  void,  and  the 
sequence  denoted  by  as  oragna  s  ■’S  empty.  The  as  deci  s  attribute  is  a  sequence 
having  a  null_comp  decl  node  as  its  first  elemenc,  and  any  number  of  pragma 
nodes  after  it. 

If  the  record  is  not  a  null  record  then  as  dec]  s  is  a  possibly  empty 
sequence  which  can  contain  nodes  of  type  variab leaded  and  pragma.  If  the 
record  type  does  not  have  a  variant  part  then  as  variant  part  is  void  and 
as  prafjma  s  is  empty.  It  is  not  possible  for  as  decl  s  to  be  empty  a-'d 
as  variant  part  to  be  void  in  the  same  '  np_list  node. 


3.10.15  index 

The  index  node  represents  an  undefined  range,  and  appears  only  in  sequences 
associated  with  unconstrained  array  types  and  unconstrained  array  definitions 
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(such  sequences  are  denoted  by  the  as  index  s  attribute  of  the  the  array  and  the 
unconstrained_array_def  nodes).  TRi  as  name  attribute  refers  to  the 
used_nane  id  or  selicted  node  corresponding  to  the  type  mark  given  in  the  index 
subtype  Hefinition.  The  sm  type  spec  attribute  references  the  TYPE_SPEC  node 
associated  with  the  type  mark. 


discrete  range 
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VARIANT  PART 


TEST  CLAUSE  ELEM 
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CHAPTER  4 


RATIONALE 


Section  4.1 


DESIGN  DECISIONS 


4.1  DESIGN  DECISIONS 

During  the  course  of  designing  DIANA  many  design  decisions  were  affected  by 
the  need  to  adhere  to  the  design  principles  set  forth  in  the  first  chapter  of 
this  document.  This  section  discusses  some  of  these  decisions  and  the  reasons 
that  they  were  made.  Each  subsection  explains  the  design  decisions  pertaining 
to  a  particular  design  principle. 


4.1.1  INDEPENDENCE  OF  REPRESENTATION 

One  of  the  major  design  principles  of  DIANA  requires  that  the  definition  of 
DIANA  be  representation  independent.  Unfortunately,  some  of  the  information 
which  should  be  included  in  a  DIANA  structure  is  implementation-dependent.  For 
example,  DIANA  defines  a  source  position  attribute  for  each  node  which 
represents  source  code.  This  attribute  is’useful  for  reconstructing  the  source 
program,  for  reporting  errors,  for  source-level  debuggers,  and  so  on.  It  is 
not,  however,  a  type  that  should  be  defined  as  part  of  this  standard  since  each 
computer  system  has  idiosyncratic  notions  of  how  a  position  in  the  source 
program  is  encoded.  For  that  matter,  the  concept  of  source  posUion  may  not  be 
meaningful  if  the  DIANA  arises  from  a  syntax  editor.  For  these  reasons, 
attributes  such  as  source  position  are  merely  defined  to  be  private  types. 

A  private  type  names  an  implementation-specific  data  structure  that  is 
inappropriate  to  specify  at  the  abstract  structure  level.  DIANA -defines  six 
private  types.  Each  of  these  corresponds  to  one  of  the  kinds  of  information 
which  may  be  installation  or  target  machine  specific.  They  include  types  for 
the  source  position  of  a  node,  the  representation  of  identifiers,  the 
representation  of  various  values  on  the  target  system,  and  the  representation  of 
comments  from  the  source  program.  The  DIANA  user  must  supply  an  implementation 
for  each  of  these  types. 

As  is  explained  in  the  Ada  reference  manual,  a  program  is  assumed  to  be 
compiled  in  a  'standard  environment'.  An  Ada  program  may  explicitly  or 
implicitly  reference  entities  defined  in  this  environment,  and  the  DIANA 
representation  of  the  program  must  reflect  this.  The  entities  that  may  be 
referenced  include  the  predefined  attributes  and  types.  The  DIANA  definition  of 
these  entities  is  not  given  in  this  document  but  is  assumed  to  be  available. 
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4. 1.1.1  SEPARATE  COMPILATION 

It  would  not  be  appropriate  for  DIANA  to  provide  the  library  management 
upon  which  separate  compilation  of  Ada  program  units  is  based.  Nonetheless,  the 
possibility  of  separate  compilation  affects  the  design  of  DIANA.  The 
intermediate  representation  of  a  previously  compiled  unit  may  need  to  be  used 
again.  Furthermore,  all  of  the  information  about  a  program  unit  may  not  be 
known  when  it  is  first  compiled. 

The  design  of  DIANA  carefully  avoids  constraints  on  a  separate  compilation 
system,  aside  from  those  implied  directly  by  the  Ada  language.  The  design  can 
be  extended  to  cover  the  full  APSE  requirements! 3].  Special  care  has  been  taken 
that  several  versions  of  a  unit  body  can  exist  corresponding  to  a  single 
specification,  that  simultaneous  compilation  within  the  same  project  is 
possible,  and  that  units  of  other  libraries  can  be  used  effectively  [5].  The 
basic  decision  which  makes  these  facilities  implementable  is  to  forbid  forwarc 
references. 

Certain  entities  may  have  more  than  one  definition  point  in  Ada.  In  such 
cases,  DIANA  restricts  the  attribute  values  of  all  of  the  defining  occurrences 
to  be  identical.  In  the  presence  of  separate  compilation  the  requirement  that 
the  values  of  the  attributes  at  all  defining  occurrences  are  the  same  cannct 
always  be  met.  The  forward  references  assumed  by  DIANA  are  void  in  these  cases. 
The  reasons  for  this  approach  are: 

0  A  unit  can  be  used  even  when  the  corresponding  body  is  not  yet 
compiled.  In  this  case,  the  forward  reference  must  have  the  value  void 
since  the  entity  does'  not  exist. 

0  Updating  a  DIANA  representation  would  require  write  access  to  a  file' 
which  may  cause  synchronization  problems  (see  [5]). 

0  A  library  system  may  allow  for  several  versions  of  bodies  for  the  same 
specification.  If  an  attribute  were  updated  its  previous  value  would 

be  overwritten.  Moreover,  the  maintenance  of  different  versions  shoulo 
be  part  of  the  library  system  and  should  not  influence  the  intermediate 
representation. 


4.1.2  EFFICIENT  IMPLEMENTATION  AND  SUITABLITY  FOR  VARIOUS  KINDS  OF  PROCESSING 

The  design  goals  of  efficient  realization  and  suitability  for  many  kinds  of 
processing  are  interrelated.  It  was  necessary  to  define  a  structure  containing 
the  information  needed  to  perform  different  kinds  of  processing  without 
overburdening  any  one  kind  of  processing  with  the  task  of  computing  and 
retaining  a  great  deal  of  extraneous  information. 

Since  many  tools  will  be  manipulating  the  source  text  in  some  way,  it  was 
decided  that  DIANA  should  retain  the  structure  of  the  original  source  program. 
In  order  to  do  this,  structural  attributes  were  defined.  These  attributes 
define  a  tree  representing  the  original  source.  It  is  always  possible  to 
regenerate  the  source  text  from  its  DIANA  form  (except  for  purely  lexical 
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issues,  such  as  the  placement  of  comments)  by  merely  traversing  the  nodes 
denoted  by  structural  attributes. 

Unfortunately,  the  structure  of  the  original  source  program  is  not  always 
suitable  for  semantic  processing.  Hence,  semantic  attributes  were  added  to 
augment  the  structural  ones.  These  attributes  transform  the  DIANA  structure 
from  a  tree  to  a  network.  In  some  cases  these  attributes  are  merely  "shortcuts" 
to  nodes  which  are  already  in  the  DIANA  structure,  but  in  other  cases  semantic 
attributes  denote  nodes  which  do  not  correspond  to  source  text  at  all. 

In  the  process  of  adding  semantic  attributes  to  the  definition  of  DIANA,  it 
was  necessary  to  decide  which  information  should  be  represented  explicitly  and 
which  should  be  recomputed  from  stored  information.  Obviously,  storing  as 
little  information  as  possible  makes  the  DIANA  representation  smaller;  however, 
such  an  approach  also  increases  the  time  required  for  semantic  processing. 
Storing  all  of  the  information  required  would  improve  processing  speed  at  the 
expense  of  storage  requirements.  The  attribution  principles  of  DIANA  are  a 
compromise  between  these  extremes. 

In  order  to  decide  whether  or  not  to  include  a  particular  attribute  the 
following  criteria  were  considered: 

0  DIANA  should  contain  only  such  information  as  would  be  typical 'y 
discovered  via  static  (as  opposed  to  dynamic)  semantic  analysis  of  the 
original  program, 

0  If  information  can  be  easily  recomputed,  it  should  be  omitted. 

These  two  points  are  discussed  at  length  in  the  following  two  subsections. 


4. 1.2.1  STATIC  SEMANTIC  INFORMATION 

DIANA  includes  only  the  information  that  is  determined  from  STATIC  semantic 
analysis,  and  excludes  information  whose  determination  requires  DYNAMIC  semantic 
analysis. 

This  decision  affects  the  evaluation  of  non-$tat’c  exoressic's  and 
evaluation  of  exceptions.  For  examole,  the  attribute  ^m_value  should  not  be 
used  to  hold  the  value  of  an  expression  that  is  not  static,  ever,  if  an 
implementation's  semantic  analyzer  is  capable  of  evaluating  some  sucn 
expressions.  Similarly,  exceptions  are  part  of  the  execution  (i.e.  dynamic) 
semantics  of  Ada  and  should  not  be  represented  in  DIANA.  Thus  the  attribute 
sm  value  is  not  used  to  represent  an  exception  to  be  raised. 

Of  course,  an  implementation  that  does  compute  these  additional  values  may 
record  the  information  by  defining  additional  attributes.  However,  any  DIAN^ 
consumer  that  relies  on  these  attributes  cannot  be  considered  a  correct  DIANA 
"user",  as  defined  in  this  document. 
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4. 1.2.2  WHAT  IS  'EASY  TO  RECOMPUTE'? 

Part  of  the  criteria  for  including  an  attribute  in  DIANA  is  that  it  should 
be  omitted  if  it  is  easy  to  recompute  from  the  stored  information.  It  is 
important  to  avoid  such  redundant  encodings  if  DIANA  is  to  remain  an 
implementable  Internal  representation.  Of  course,  this  guideline  requires  a 
definition  of  this  phrase. 

An  attribute  is  easily  computed  if: 

0  it  requires  visits  to  no  more  than  three  to  four  nodes;  or 

0  it  can  be  computed  in  one  pass  through  the  DIANA  tree,  and  all  nodes 
with  this  attribute  can  be  computed  in  the  same  pass. 


The  first  criterion  is  clear;  the  second  requires  discussion. 

Consider  first  an  attribute  that  is  needed  to  perform  semantic  analysis. 
As  an  implementation  is  building  a  DIANA  structure,  it  is  free  to  create  extra 
(non-DIANA)  attributes  for  its  purposes.  Thus  the  desired  attributes  can  be 
created  by  those  implementations  that  need  them.  To  require  these  attributes  to 
be  represented  by  all  DIANA  users  is  an  imposition  on  implementations  which  use 
algorithms  that  do  not  require  these  particular  attributes. 

Consider  now  an  attribute  needed  to  perform  code  generation.  As  long  as 
the  attribute  can  be  determined  in  a  single  pass,  the  routine  that  reads  in  the 
DIANA  can  readily  add  it  as  it  reads  in  the  DIANA.  Again,  some  implementors  may 
not  need  the  attribute,  and  it  is  inappropriate  to  burden  all  users  with  it. 

It  is  for  these  reasons  that  suggestions  for  pointers  to  the  enclosing 
compilation  unit,  pointers  to  the  enclosing  namescope,  and  back  pointers  in 
general  have  been  rejected.  These  are  attributes  that  are  easily  computed  in 
one  pass  through  the  DIANA  tree  and  indeed  may  not  be  needed  by  all 
implementations. 

Of  course,  a  DIANA  producer  can  create  a  structure  with  extra  attributes 
beyond  those  specified  for  DIANA.  Nevertheless,  any  DIANA  consumer  that  relies 
on  these  additional  attributes  is  not  a  DIANA  "user",  as  defined  in  f'is 
document. 


4.1.3  REGULARITY  OF  DESCRIPTION 

In  order  to  increase  the  clarity  of  the  DIANA  description,  it  was  decided 
that  the  class  structure  of  DIANA  should  be  a  hierarchy.  Unfortunately,  some 
nodes  should  belong  in  more  than  one  class.  To  circumvent  this  problem,  several 
intermediate  nodes  were  defined,  nodes  for  which  the  only  non-lexical  attribute 
denotes  a  node  that  already  belongs  to  another  class.  These  intermediate  nodes 
do  not  convey  any  structural  or  semantic  information  beyond  the  value  of  the 
non-lexical  attribute.  DIANA  contains  the  following  intermediate  nodes: 


block  master 
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discrete  subtype 

1nteger_3ef 

float_def 

f1xed~def 

cho1ce_^exp 

choice~range 

stn_pragma 

se 1 ect_a 1 t_pr agma 

al  ternat  1  ve_pragina 

comp_rep_pragma 

context_pragma 

var1ant~pragma 

It  should  be  noted  that  not  all  nodes  containing  a  single  non-lexical 
attribute  are  intermediate  nodes.  For  instance,  the  renaines_unit  node  has  a 
single  non-lexical  attribute  as  name;  however,  the  renaBes_unit  node  is  not  an 
intermediate  node  because  it  is  used  to  convey  the  fact  that  a  unit  has  been 
renamed,  in  addition  to  recording  the  name  of  the  original  unit  via  the  as  name 
attribute.  On  the  other  hand,  the  cho1ce_exp  node  was  introduced  merely  because 
the  class  EXP  could  not  be  included  in  both  ASSOC  and  CHOICE.  It  contains  no 
more  information  than  the  EXP  node  denoted  by  its  as  exp  attribute. 

It  is  not  the  intention  of  DIANA  to  require  that  intermediate  nodes  be 
represented  as  such;  they  are  included  in  the  definition  of  DIANA  only  to 
maintain  a  hierarchy.  This  is  a  natural  place  for  an  implementation  to  optimize 
its  internal  representation  by  excluding  the  intermediate  nodes,  and  directly 
referencing  each  node  denoted  by  the  non-lexical  attribute  of  an  intermediate 
node. 


In  the  DIANA  description,  attributes  are  defined  at  the  highest  possible 
level;  i.e.  if  all  of  the  nodes  of  a  class  have  the  same  attribute  then  the 
attribute  is  defined  on  the  class  rather  than  on  the  individual  nodes.  In  this 
way  a  node  may  "inherit"  attributes  from  the  class  to  which  it  belongs,  and  from 
the  class  to  which  that  class  belongs,  etc. 

The  node  void  receives  a  slightly  different  treatment  than  the  other  DIANA 
nodes.  It  is  the  only  node  which  violates  the  DIANA  hierarchy,  and  it  is  the 
only  node  which  inherits  attributes  which  cannot  be  used.  The  node  void 
represents  "nothing".  It  maj  be  thought  of  as  a  null  pointer,  aUhCugh  it  does 
not  have  to  be  represented  as  such.  Instead  of  requiring  a  different  kind  of 
void  node  for  each  class  to  which  void  belongs,  void  was  allowed  to  belong  to 
more  than  one  class  (thus  constituting  the  only  exception  to  the  hierarchy). 
Because  void  is  a  member  of  many  classes,  it  inherits  numerous  attributes. 
Rather  than  move  the  attribute  definitions  from  the  classes  and  put  them  on  all 
of  the  constituent  nodes  except  for  void,  it  was  decided  to  allow  void  to 
inherit  attributes.  Since  it  is  meaningless  for  "nothing"  to  have  attributes,  a 
restriction  was  added  to  the  semantic  specification  of  DIANA.  The  attributes  of 
void  may  not  be  manipulated  in  any  way;  they  cannot  be  set  or  examined,  hence 
they  are  in  effect  not  represented  in  a  DIANA  structure. 


Section  4.2 
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4.2  DECLARATIONS 

Explicit  declarations  are  represented  in  a  DIANA  structure  by  declarative 
nodes.  These  nodes  preserve  the  source  text  for  source  reconstruction  and 
conformance  checking  purposes.  They  do  not  record  the  results  of  semantic 
analysis;  that  information  is  contained  in  the  corresponding  defining  occurrence 
nodes.  All  declarative  nodes  have  a  child  that  is  a  node  or  sequence  of  nodes 
(of  type  SOURCE_NAME)  representing  the  identi f ier(s)  used  to  name  the  newly 
defined  entity  or“entities. 

Declarative  nodes  are  members  of  class  ITEM.  The  nodes  in  class  ITEM  are 
grouped  according  to  similarities  in  the  syntax  of  the  code  that  they  represent 
and  similarities  in  the  context  in  which  they  can  appear. 


4.2.1  MULTIPLE  ENTITY  DECLARATIONS 

Certain  kinds  of  declarations  --  object  declarations,  number  declarations, 
discriminant  declarations,  component  declarations,  parameter  declarations,  and 
exception  declarations  --  can  introduce  more  than  one  entity.  The  nodes 
corresponding  to  these  declarations  belong  to  two  different  classes, 
DSCRMT_PARAM_DECL  and  ID_S_0ECL,  both  of  which  define  an  as  source  name  s 
attribute.  "These  classes  are  distinguished  from  eacn  other  because  they  appear 
in  different  contexts.  Discriminant  declarations  can  appear  only  in 
discriminant  parts,  and  parameter  declarations  can  appear  only  in  formal  parts. 
The  remaining  multiple  entity  declarations  are  basic  declarative  items,  and  can 
appear  in  declarative  parts.  In  addition,  the  basic  declarative  items  can 
appear  in  sequences  containing  pragmas,  which  cannot  be  given  in  discriminant 
parts  or  formal  parts. 

ID  S  DECL  is  further  subdivided  into  classes  according  to  the  syntactic 
similarTtTes  of  the  declarations  it  represents.  For  instance,  object 
declarations  and  number  declarations  may  have  (default)  initial  values,  hence 
constant_decl ,  variable_decl ,  and  number_decl  belong  to  class  EXP_DECL,  which 
defines  an  as  exp  attribute  to  record  that  value. 


4.2. 1.1  OBJECT  DECLARATIONS  AND  COMPONENT  DECLARATIONS 

The  type  portion  of  object  declarations  may  be  given  in  two  different  ways: 
either  by  a  subtype  indication  or  a  constrained  array  definition.  Tne  node 
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constrained_array_def  is  already  a  member  of  class  TYPE_^DEF,  which  represents 
the  syntax”  of  type  definitions.  Rather  than  include  constrained  array_def  in 
another  class  and  disrupt  the  heirarchy,  the  node  subtype  indication  was”  added 
to  class  TYPE_0EF.  Thus  the  class  0BJECT__0ECL,  which  comprises  the  nodes 
constant_dec1  and  variable  decl,  defines  the  attribute  as  type  def  to  represent 
the  type  specification  given  in  the  object  declaratiofu  Obviously  as  type  def 
cannot  denote  any  kind  of  TYPE_DEF  node  other  than  su b ty pe_ indication  and 
constra1ned_array__def  in  this  particular  context. 

The  only  other  kind  of  declaration  which  introduces  objects  and  does  not 
require  the  type  specification  to  be  a  type  mark  is  a  component  declaration,  the 
type  portion  of  which  is  given  by  a  subtype  Indication.  Rather  than  define  a 
node  exclusively  for  component  declarations,  they  are  represented  by  the  same 
kind  of  node  as  variable  declarations,  since  the  variable_decl  node  allows 
subtype  indications  for  the  as  type  def  attribute.  This”is  also  convenient 
because  component  declarations  may  be  interspersed  with  pragmas,  and  both  pragma 
and  variable  decl  belong  to  class  DECL  (a  sequence  of  compcne''t  declarations  is 
represented  Ey  a  decl  s  sequence).  Component  declarations  and  variable 
declarations  may  be  distinguished  by  the  fact  that  they  appear  in  different 
contexts,  and  by  the  type  of  nodes  in  the  as  source  name  s  sequence.  The  former 
contains  coaponent_1d  nodes  and  the  latter  contains  variable_id  nodes. 

A  record  component  list  may  contain  the  reserved  word  "NULL"  rather  than 
component  declarations  or  a  variant  part.  This  is  indicated  by  the  insertion  of 
a  nun_coiiip_decl  node  instead  of  variable_dec1  nodes  in  the  sequence  of 
component  declarations.  Hence  it  was  necessary  to  include  the  null_comp_decl 
node  in  class  DECL.  It  is  convenient  for  the  nun_coinp_decl  node  to  be  part  of 
a  sequence  because  it  may  be  followed  by  pragmas  (a  pragma  can  appear  after  a 
semicolon  delimiter).  Although  null_comp_decl  belongs  to  DECL,  the  ONLY  place 
that  it  can  appear  in  a  DIANA  structure  Is  as  the  first  node  in  the  as  decl  s 
sequence  of  the  compjlist  node  (this  restriction  is  given  in  the  semantic 
specification  of  DIANA). 


4.2.2  SINGLE  ENTITY  DECLARATIONS 

The  remaining  kinds  of  declarations  introduce  single  entities.  They  are 
represented  by  the  classes  SUBUNIT  BODY  and  ID_DECL.  L'ke  the  c'^asses 
DSCRMT_PARAM_DECL  and  ID_S_0ECL.  SUBUNTTBODY  and  ID_0ECL  are  distinau’shec 
because  they  represent”  declarative  items  wnicn  occur  m  different  contexts. 
SUBUNIT_BO0Y  represents  body  declarations,  both  proper  body  and  stub 
declarations.  These  declarations  are  separated  from  the  declarations  in  ID_DECL 
because  body  declarations  are  exclusively  later  declarative  items  (the”  few 
members  of  ID  DECL  that  are  later  declarative  items  are  basic  declarative  items 
as  well).  ID_DeCL  contains  basic  declarative  items  and  items  that  can  appear  in 
task  specifications. 

Body  declarations  include  subprogram  body  declarations,  package  body 
declarations,  task  body  declarations,  and  stub  declarations.  These  declarations 
are  represented  by  the  nodes  subprogram_body,  package_body,  and  task_body.  The 
difference  between  a  proper  body  and  a  stub  is  indicated  by  the  value  of  the 
asbody  attribute,  a  block  body  in  the  former  case,  and  a  stub  in  the  latter. 
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4.2.2. 1  PROGRAM  UNIT  DECLARATIONS  AND  ENTRY  DECLARATIONS 

Due  to  syntactic  similarities,  declarations  of  entries  and  program  units 
other  than  tasks  are  represented  by  nodes  from  class  UNIT_DECL,  which  contains 
only  three  members:  generic_decl,  subprog_entry_decl ,  and”  package_decl .  The 
combination  of  the  kind  of”node  representing  the  declaration  and  the  values  of 
the  as  header  and  as  unit  kind  attributes  uniquely  determine  the  exact  form  of 
the  declaration.  The  different  kinds  of  declarations  are  listed  with  their 
appropriate  attribute  values  in  Table  4.1. 

The  HEADER  and  UNIT_KIND  nodes  also  record  information  peculiar  to  that 
sort  of  declaration.  For  example,  the  renames_unit  node  not  only  indicates  that 
a  declaration  is  a  renaming  declaration,  but  ritains  the  name  of  the  original 
unit  as  wel 1 . 

A  task  declaration  can  introduce  either  a  task  type,  or  a  single  task 
object  with  an  anonymous  type,  depending  on  whether  or  not  the  declaration 
contains  the  reserved  word  "type".  The  syntax  of  a  task  declaration  differs 
from  that  of  an  ordinary  type  or  object  declaration,  hence  the  type  decl  and 
variable_decl  nodes  are  not  suitable  for  representing  a  task  declaration. 
Because  ”the  same  information  is  given  in  the  task  declaration  regardless  of  the 
kind  of  entity  it  introduces,  a  task_decl  node  represents  both  kinds  of  task 
declarations.  If  the  defining  occurrence  associated  with  the  declaration  is  a 
var1able_1d  then  the  declaration  creates  both  an  object  and  a  type;  if  the 
def ining”occurrence  is  a  type_id  then  the  declaration  creates  a  type. 

Since  a  task  declaration  always  defines  a  new  task  type,  a  new  task  type 
specification  (a  task  node)  is  created  for  each  declaration.  If  the  type  is 
anonymous  it  is  introduced  by  the  sm  ob j  type  attribute  of  the  variable_id; 
otherwise  the  task  node  is  introduced  by  the  sm  type  spec  attribute  of”the 

type_id. 

It  should  be  noted  that  a  task  object  may  also  be  declared  with  an  ordinary 
object  declaration.  Since  declarative  nodes  record  the  synt3«  of  the 
declaration,  a  variable_decl  node  rather  than  a  task_decl  node  denotes  the 
declaration  in  this  case.  This  kind  of  declaration~does  not  inf^oduce  a  new 
task  type,  thus  a  new  task  type  specification  is  not  created  for  the  task 
object(s) . 
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declaration,  at  which  point  the  context  indicates  whether  or  not  the  declaration 
and  its  defining  occurrence(s)  are  generic. 


4.2.5  IMPLICIT  DECLARATIONS 

The  Ada  programming  language  defines  different  kinds  of  implicit 
declarations.  Certain  operations  are  implicitly  declared  after  a  type 
definition  (including  derived  subprograms  following  a  derived  type  definition). 
Labels,  loop  names,  and  block  names  are  implicitly  declared  at  the  end  of  the 
corresponding  declarative  part.  These  declarations  are  not  explicitly 
represented  in  DIANA;  to  do  so  would  interfere  with  source  reconstruction. 

Since  a  label,  loop  name,  or  block  name  can  be  associated  with  only  one 
statement,  and  the  label  or  name  precedes  that  statement  in  the  source  text,  it 
is  natural  for  the  defining  occurrence  of  a  label  (a  label_id)  to  be  its 
appearance  in  a  labeled  statement,  and  the  defining  occurrence  of  a  bl'^ck  or 
loop  name  (a  block_loop_id)  to  be  its  appearance  in  a  block  or  loop  statement. 

Implicitly  declared  operations  and  derived  subprograms  are  associated  with 
a  single  type  definition.  Unfortunately,  the  names  of  these  operations  and 
derived  subprograms  are  not  used  in  that  type  definition.  As  a  result,  there  is 
no  appropriate  structural  attribute  to  introduce  the  defining  occurrences  of  the 
operations  associated  with  a  type.  All  appearances  of  the  names  of  these 
operations  and  derived  subprograms  are  represented  in  the  DIANA  structure  as 
used  occurrences.  A  defining  occurrence  still  exists  for  each  such  operation  or 
derived  subprogram;  however,  it  can  only  be  referenced  by  semantic  attributes. 
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4.3  SIMPLE  NAMES 

Simple  names  comprise  identifiers,  character  literals,  and  operator 
symbols. 

The  attributes  lx  srcpos  and  lx  comments  are  defined  for  all  DIANA  nodes 
that  represent  source  code.  An  implementation  has  the  option  of  including  these 
attributes  or  not;  however,  if  an  implementation  does  choose  to  include  them 
then  it  is  necessary  to  have  a  distinct  node  for  every  occurrence  of  a  simple 
name  in  the-  source  code.  Since  it  is  not  desirable  to  have  to  copy  all  of  the 
semantic  attributes  associated  with  the  name  of  an  entity  every  time  the  name  is 
used,  the  appearances  of  simple  names  in  a  DIANA  tree  are  divided  into  defining 
and  used  occurrences.  The  former  are  represented  by  class  DEF_NAME  and  the 
latter  by  class  DESIGNATOR. 

In  order  to  avoid  constraining  an  implementation,  DIANA  does  not  REQUIRE 
that  a  distinct  used  occurrence  node  be  created  for  every  use  of  a  simple  name. 
A  single  used  occurrence  node  may  be'created  for  a  particular  name,  and  all 
references  to  that  entity  in  the  source  code  may  be  represented  by  references  to 
that  single  used  occurrence  node  in  the  DIANA  structure. 

The  defining  nodes  for  entities  together  with  their  attributes  play  the 
same  role  as  a  dictionary  or  symbol  table  in  conventional  compiler  strategy. 
Unless  there  is  interference  from  separate  compilation,  it  is  possible  for  all 
information  about  an  entity  to  be  specified  by  attributes  on  its  defining  node. 
The  node  for  a  used  occurrence  of  an  entity  always  refers  back  to  this  defining 
occurrence  via  the  sm  defn  attribute. 

Defining  occurrences  are  represented  by  different  kinds  of  nodes  rather 
than  a  single  const-^uct,  thereby  allowing  the  appropriate  semantic  attributes  to 
be  attached  to  each.  For  instance,  the  defining  occurrence  of  a  discriminant  is 
represented  by  a  d1scriminant_id,  which  has  an  attribute  to  record  the 
applicable  component  clause  (if  there  is  one);  the  definii.g  occurrence  of  a 
constant  is  represented  by  a  constant_id,  which  has  an  attribute  that  references 
the  applicable  address  clause  (if  there  is  one). 

DIANA  also  distinguishes  the  kinds  of  usage  depending  on  the  properties  of 
the  entity  that  is  referenced.  For  example,  a  used  occurrence  of  an  object  name 
is  represented  by  a  used_object_id,  while  that  of  an  operator  is  represented  by 
a  used  op. 
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DIANA  has  the  following  set  of  defining  occurrences. 

attribute  Id 
arguaent_Td 
b1ock_1oop  Id 
b 1 tn_operaIor_ i d 
character_1d  “ 
coaponent~1d 
constant_Td 
d1scriiilf5ant_id 
entry_id 
enuaefatlon  Id 
exception  l3 
function  Td 
generic_Td 
Iteration  id 
1n__1d 
1n“out  Id 
laEel_Td 

l_private_type_id 
number_id” 
operator_id 
out  id 
pacicage  Id 
pragma_Td 
pr1vate_type_id 
procedure  Id” 
subtype  l3 
task_bo3y_id 
type” id 
variible_id 

and  the  following  set  used  occurrences: 

used_char 

used”name_id 

used~object_id 

used”op 


4.3.1  DEFINING  OCCURRENCES  OF  PREDEFINED  ENTITIES 

The  consistency  of  this  scheme  requires  the  provision  of  a  definition  point 
for  predefined  identifiers  as  well.  Although  these  nodes  will  never  be 
introduced  by  a  structural  attribute  because  they  do  not  have  an  explicU 
declaration,  they  car,  be  referenced  by  the  sm  defn  attribute  of  a  node 
corresponding  to  a  used  occurrence. 

Certain  kinds  of  entities,  such  as  exceptions,  may  be  either  predefined  or 
user-defined.  Such  an  entity  is  represented  by  the  same  kind  of  node  in  either 
case  --  a  node  from  class  SOURCE_NAME,  which  represents  the  defining  occurrences 
of  all  entities  which  can  by  declared  by  the  user.  If,  however,  a  SOURCE_NAME 
node  corresponds  to  a  predefined  entity  then  the  lx  srcpos  and  lx  comments 
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attributes  will  be  undefined  since  it  does  not  correspond  to  source  text. 

Other  entities  can  never  be  declared  by  the  user;  i.e.  pragmas,  pragma 
argument  identifiers,  and  attributes.  These  entities  are  represented  by  nodes 
from  class  PREDEF  NAME;  the  lx  srcpos  and  lx  consents  attributes  of  nodes 
belonging  to  this  class  are  never  defined^  PREDEF_NAME  also  contains  nodes 
corresponding  to  defining  occurrences  of  the  predefined  operators  (these 
operators  cannot  be  declared  by  the  user,  although  they  may  be  overloaded).  A 
user-defined  operator  is  represented  by  a  node  from  class  SOURCE  NAME. 


4.3.2  MULTIPLE  DEFINING  OCCURRENCES 

In  general,  every  entity  has  a  single  defining  occurrence.  In  the 
instances  where  multiple  defining  occurrences  can  occur,  each  defining 
occurrence  is  represented  by  a  DEF_NAME  node. 

The  entities  which  may  have  multiple  defining  occurrences  are: 


(a) 

deferred  constants 

(b) 

incomplete  types 

(c) 

non-generic  (limited)  private 

types 

(d) 

discriminants  of  incomplete  or 

(limited)  private  types 

(e) 

non-generic  formal  parameters 

(f) 

program  units 

With  the  exception  of  tasks  and  (limited)  private  types,  the  different 
defining  occurrences  of  one  of  these  entities  are  represented  by  the  same  kind 
of  node.  In  addition,  the  different  defining  occurrences  have  the  same 
attribute  values  (certain  incomplete  types  and  program  units  may  have  attributes 
which  cannot  be  set  in  the  first  defining  occurrence  due  to  i Rter*e’^ence  by 
separate  compilation;  however,  this  ’s  an  exception  rather  than  a  rule),  ^hese 
defining  occurrences  have  an  attribute,  sm  first,  that  refers  to  the  node  for 
the  first  defining  occurrence  of  the  identifier,  similar  to  the  sm  pefn 
attribute  of  used  occurrences.  The  node  that  is  the  first  defining  occurrence 
has  an  sm  first  attribute  that  references  itself. 

All  used  occurrences  must  reference  the  same  defining  occur’^ence,  the  one 
that  occurs  first.  Nevertheless,  the  attributes  for  all  defining  occurrences  of 
an  entity  must  still  be  set  with  the  appropriate  values. 

An  entry  declaration  and  its  corresponding  accept  statement  are  not  treated 
as  different  definition  points  of  the  same  entity.  Thus  the  entry_id  is  the 
unique  defining  occurrence;  a  used_name_id  appears  in  an  accept  statement,  the 
sm  defn  attribute  of  which  refers  to  the  associated  entry  id.  Howcvc'-,  the 
formal  parts  of  the  entry  declaration  and  the  accept  statement”  multiply  define 
the  entry  formal  parameters. 


DIANA  Reference  Manual  Draft  Revision  4 
RATIONALE 


Page  4-16 


Any  names  appearing  in  a  record  representation  clause  or  dn  enumeration 
representation  clause  are  considered  used  occurrences;  this  includes  the  names 
of  record  types,  record  components,  and  enumeration  literals. 


4.3.2. 1  MULTIPLE  DEFINING  OCCURRENCES  OF  TYPE  NAMES 

There  are  two  forms  of  type  declaration  in  which  information  about  the  type 
is  given  at  two  different  places:  Incomplete  and  private.  In  addition  to  the 
multiple  defining  occurrences  of  the  type  names  there  are  multiple  defining 
occurrences  of  the  discriminant  names  if  the  types  include  discriminant  parts. 

The  notion  of  an  incomplete  type  permits  the  definition  of  mutually 
dependent  types.  Only  the  new  name  is  introduced  at  the  point  of  the  incomplete 
type  declaration  --  the  structure  of  the  type  is  given  in  a  second  type 
declaration  which  generally  must  appear  in  the  same  declarative  part.  The 
defining  occurrences  of  both  types  are  described  by  type_id  nodes  which  have  the 
semantic  attribute  sm  type  spec.  With  one  exception  (which  is  discussed  in  the 
following  paragraph')  tRe  full  type  declaration  must  occur  in  the  same 
declarative  part,  hence  the  sm  type  spec  attribute  of  both  defining  occurrences 
can  denote  the  full  type  specification. 

A  special  case  may  be  introduced  when  an  incomplete  type  declaration  occurs 
within  the  private  part  of  a  package  specification.  The  full  type  declaration 
is  not  required  to  appear  in  the  same  declarative  part;  it  may  be  given  in  the 
declarative  part  of  the  package  body,  which  is  not  necessarily  in  the  same 
compilation  unit.  Since  forward  references  are  not  allowed  in  DIANA,  if  the 
full  type  declaration  is  in  a  separate  compilation  unit  then  the  sm  type  spec 
attribute  of  the  type_id  corresponding  to  the  incomplete  type  declaration 
denotes  a  special  incomplete  node  (which  is  discussed  in  detail  in  the  section 
on  types).  The  sm  type  spec  attribute  of  the  node  for  the  full  type  declaration 
references  the  full  type  specification. 

Private  types  are  used  to  hide  information  from  the  user  of  a  package;  a 
private  type  declaration  appears  in  the  visible  part  of  a  package  without  any 
structural  information.  The  full  declaration  is  given  in  the  private  part  of 
the  package  specification  (this  restriction  ensures  that  there  is  no 
interference  from  separate  compilation).  Unfortunately,  the  solution  used  for 
incomplete  types  cannot  be  aoplied  to  private  types  --  if  both  de^’n-''>g 
occurrences  had  the  same  node  type  and  attributes,  it  could  not  be  determined 
whether  the  type  is  a  private  one  or  not.  This  information  is  important  when 
the  type  is  used  outside  of  the  package. 

DIANA  views  the  declarations  as  though  they  were  declarations  of  different 
entities  --  one  is  a  private  type  and  the  other  a  normal  one.  Both  denote  the 
same  type  structure  in  their  sm  type  spec  attribute,  however.  The  distinction 
is  achieved  by  introducing  a  new  iTTnd  of  a  defining  occurrence,  namely  the 
pr1vate_type_^1d.  It  has  the  attribute  sm  type  spec  which  provides  access  to  the 
structural  Information  given  in  the  full  type  declaration.  Limited  private 
types  are  treated  in  the  same  manner,  except  that  their  defining  occurrence  is  a 
l_private_type_1d.  In  the  case  of  (limited)  private  types  the  sm  first 
attribute”  of”  the  type  id  node  refers  to  the  private_type3Td  or 
l_pr1vate_type_id.  The  pr?vate_type_id  and  l_pr1vate_type  Id  nodes  do  not  have 
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an  sm  first  attribute  because  they  always  represent  the  first  defining 
occurrence  of  the  type  name. 


4. 3. 2. 2  MULTIPLE  DEFINING  OCCURRENCES  OF  TASK  NAMES 

The  only  other  entity  to  have  its  different  defining  occurrences 
represented  by  different  kinds  of  nodes  is  the  task.  Although  a  task  is  a 
program  unit,  its  defining  occurrences  cannot  be  treated  like  those  of  other 
program  units.  The  declaration  of  a  task  introduces  either  a  task  type  or  a 
task  object  having  an  anonymous  type,  hence  the  first  defining  occurrence  of  a 
task  name  is  represented  by  a  type_i<'  or  a  variable_1d.  Any  subsequent  defining 
occurrences  of  the  task  name  must  correspond  to  either  a  stub  declaration  or  a 
proper  body  declaration;  these  defining  occurrences  are  represented  by 
task_body_id  nodes. 

All  of  the  information  concerning  the  task  is  stored  in  the  type 
specification  of  the  task.  Even  though  used  occurrences  of  the  task  name  do  not 
reference  the  type  specification  (they  denote  the  type_id  or  variab1e_id) ,  the 
type  specification  may  be  reached  from  any  of  the  defining  occurrences? 


4.3.3  USED  OCCURRENCES 

The  nodes  representing  used  occurrences  are  included  in  the  class 
representing  expressions  because  certain  names  may  appear  in  expressions. 
Restrictions  have  been  added  to  the  semantic  specification  to  differentiate  the 
used  occurrences  which  can  appear  in  expressions  from  those  which  cannot. 

The  nodes  used_object_id  and  used_char  represent  used  occurrences  of 
entities  having  a  value  and  a  type;  these  nodes  can  appear  in  the  context  of  an 
expression.  The  former  denotes  objects  and  enumeration  literals,  the  latter 
denotes  character  literals  (in  this  way  identifiers  consisting  of  a  single 
character  are  distinguished  from  character  literals).  To  allow  the  nodes 
representing  expressions  to  be  treated  in  a  consistent  manner,  the  attributes 
sm  value  and  sm  exp  type  were  added  to  the  used_object_id  and  used_char  nodes. 

■^■he  remaining  kinds  of  used  occurrences  are  represented  by  the  used  op  and 
used_name_id  nodes.  The  occurrence  of  an  operator  is  represented  by  a  used  op, 
and  that  of  any  other  entity  by  a  used_name_id. 

The  names  of  objects  and  literals  may  appear  in  contexts  other  than 
expressions;  in  particular,  in  places  where  the  Ada  syntax  requires  a  name. 
Should  those  used  occurrences  be  represented  by  used_object_id  nodes  or 
used_naine_id  nodes?  In  some  instances  it  might  be  useful~to  have  ready  access 
to  more  information  than  ju'^t  the  name  (for  example,  the  subtype  of  the  object 
denoted  by  the  name  might  be  helpful).  Some  names  (such  as  the  "object_name"  in 
a  renaming  declaration)  must  be  evaluated  just  as  an  expression  is  evaluated. 
On  the  other  hand,  a  name  appearing  in  the  left-hand  part  of  a  named  association 
is  not  evaluated,  and  since  the  association  is  not  designed  for  semantic 
processing  (a  normalized  list  of  expressions  is  created  for  that  purpose),  it 
would  be  wasteful  to  record  additional  semantic  attributes. 
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It  was  decided  that  the  name  of  an  object  or  literal  appearing  in  the 
left-hand  part  of  a  named  association  should  be  represented  by  a  used  naae  Id 
because  the  attributes  peculiar  to  a  used_object_id  would  not  be  needed  7or 
semantic  processing  in  that  context.  "Since  the  situation  is  not  as  clear  in 
other  contexts,  all  other  uses  of  the  name  of  an  object  or  literal  are 
represented  by  used_object  Id  nodes. 
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(b)  anonymous  base  types  created  by  constrained  array  definitions  [ARM, 
3.6] 

(c)  anonymous  index  subtypes  created  by  constrained  array  definitions  [ARM, 
3.6] 

(d)  anonymous  task  types  introduced  by  task  declarations  creating  single 
task  objects  [ARM,  9.1] 

The  declarations  of  these  anonymous  types  are  not  represented  (to  do  so  would 
interfere  with  source  reconstruction),  hence  their  type  specifications  are 
introduced  by  the  appropriate  semantic  attributes.  For  instance,  the  node  for 
an  anonymous  task  type  is  introduced  by  the  sm  obj  type  attribute  of  a 
variable_id  node.  At  some  point  it  will  be  necessary  to  know  that  such  types 
are  anonymous  (i.e.  that  they  have  not  yet  been  elaborated),  consequently  the 
sm  is  anonymous  attribute  was  added  to  all  nodes  except  for  those  representing 
universal  types  (which  are  always  anonymous). 

In  order  to  maintain  the  consistency  of  this  type  representation  scheme  it 
was  necessary  to  include  some  anonymous  types  and  subtypes  which  are  not 
discussed  in  the  reference  manual. 

Type  definitions  containing  subtype  indications  with  explicit  constraints 
introduce  anonymous  subtypes.  Hence  the  component  subtype  of  an  array  or  the 
designated  subtype  of  an  access  type  may  be  anonymous.  If  the  constraints  on 
the  parent  type  and  the  parent  subtype  of  a  derived  type  are  not  the  same  then 
the  new  base  type  is  anonymous. 

Every  object  and  expression  in  DIANA  has  an  attribute  denoting  its  subtype 
(sm  obj  type  for  objects  and  sm  exp  type  for  expressions).  The  subtype 
specification  contains  the  applicable  constraint  (necessary  for  operations  such 
as  constraint  checking)  as  well  as  a  path  to  the  base  type  (which  is  required 
for  processing  such  as  type  resolution).  If  a  new  constraint  is  imposed  by  an 
object  declaration  or  an  expression  then  an  anonymous  type  specification  must  be 
created  in  order  to  record  the  new  constraint.  Object  or  component  declarations 
containing  either  a  constrained  array  definition  or  a  subtype  indication  with  an 
explicit  constraint  introduce  anonymous  subtypes  for  each  entity  in  the 
identifier  list.  Slices,  aggregates,  and  string  literals  introduce  anonymous 
subtypes  if  it  cannot  by  determined  statically  that  the  constraints  on  the 
expression  and  those  on  the  array  prefix  or  context  subtype  a-'e  the  same. 

Unlike  class  TYPE  OEF,  which  is  subdivided  according  to  syntactic 
similarities,  class  TyPE_SPEC  is  decomposed  into  subclasses  by  the  semantic 
characteristics  (i.e.  attributes)  various  members  have  in  common.  When  placing 
the  nodes  in  the  hierarchy,  certain  compromises  were  made  that  cause  a  few  nodes 
to  inherit  an  attribute  that  is  not  really  needed.  For  instance,  the 
constrained_array  and  constrained_record  nodes  inherit  the  attribute  sm  derived, 
even  though~they  can  never  represent  a  derived  type  (they  may,  however, 
represent  a  subtype  of  a  derived  type).  It  was  deemed  better  to  have  an 
occasional  unneeded  attribute  than  to  cause  confusion  by  defining  common 
attributes  in  several  different  places  (i.e.  moving  the  constrained  array  and 
constrained_record  nodes  outside  of  class  DERIVABLE_SPEC  and  duplicating  the 
attributes  sm  is  anonymous,  sm  base  type,  and  sm  depends  on  dscrmt  for  them). 
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4.4.1  CONSTRAINED  AND  UNCONSTRAINED  TYPES  AND  SUBTYPES 

A  TYPE_SPEC  node  provides  no  Indication  as  to  whether  the  entity  it 
represents  ”is  a  type  or  a  subtype.  In  the  Ada  language,  the  name  of  a  type 
denotes  not  only  the  type,  but  the  corresponding  unconstrained  subtype  as  well. 
An  attempt  at  differentiating  types  and  subtypes  would  only  cause  confusion  and 
inconsistencies.  A  distinction  is  made,  however,  between  base  types  and 
subtypes  of  base  types.  The  attribute  sm  base  type  denotes  the  base  type,  a 
type  specification  where  all  representation  and  structural  information  can  be 
found.  Obviously  the  sm  base  type  attribute  of  a  node  corresponding  to  a  base 
type  will  contain  a  self -reference. 

Certain  nodes  always  represent  base  types;  these  are  the  task  spec  node, 
and  those  in  classes  PRIVATE_SPEC  and  UNCONSTRAINED_COMPOSITE.  The  task  spec 
and  PRIVATE_SPEC  nodes  do  not  have  an  sm  base  type  attribute  at  all.  Ss  a 
result  of  "their  inclusion  in  class  N0N~TASK  the  UNCONSTRAINED  COMPOSITE  nodes 
have  inherited  this  attribute;  however,  it  always  contains  a  sel7-reference. 

DIANA  also  distinguishes  between  constrained  and  unconstrained  (sub)types 
for  the  following  classes  of  types:  array,  record,  and  access.  The  nodes  in 
class  UNCONSTRAINED  represent  unconstrained  types;  those  in  class  CONSTRAINED 
represent  constrained  types. 

This  distinction  proves  to  be  very  useful  when  performing  certain  semantic 
checks  involving  array,  record,  or  access  types.  For  instance,  the  types  in 
these  classes  may  have  index  or  discriminant  constraints  imposed  upon  them; 
however,  an  index  or  discriminant  constraint  cannot  be  imposed  on  the  type  if  it 
is  already  constrained. 

The  fact  that  an  object  is  of  an  unconstrained  type  rather  than  a 
constrained  type  may  also  affect  certain  implementation  decisions.  For  example, 
in  a  complete  assignment  to  a  record  object  of  an  unconstrained  type  that  has 
default  values  for  its  discriminants,  the  constraints  on  the  object  may  be 
changed  during  execution.  Hence  an  implementation  may  wish  to  handle  objects  of 
an  unconstrained  record  type  in  a  manner  that  is  different  from  the  way  in  which 
objects  of  a  constrained  type  are  treated. 

All  scalar  types  are  constrained,  and  may  be  further  const’^ained  any  numbe’" 
of  times.  Hence  there  is  only  one  kind  of  node  for  each  kind  of  scalar  type, 
and  each  SCALAR  node  has  an  sm  range  attribute  which  denotes  the  app'icat'e 
range  constraint.  The  nodes  for  real  types  have  an  additional  sm  accuracy 
attribute  to  record  the  value  of  the  digits  or  delta  expression.  For  some  types 
(such  as  the  predefined  types  and  enumeration  types)  the  constraints  are 
implicit,  therefore  a  range  node  which  does  not  correspond  to  source  code  must 
be  created.  The  range  node  that  i>  constructed  for  an  enumeration  type  will 
denote  the  first  enumeration  literal  as  the  lower  bound  and  the  last  enumeration 
literal  as  the  upper  bound.  The  range  node  for  a  predefined  numeric  type  will 
have  for  its  bounds  expressions  (determined  by  the  implementation)  which  do  not 
correspond  to  source  code. 

Constraints  cannot  be  applied  to  a  task  type,  therefore  the  question  of 
whether  or  not  it  is  constrained  is  irrelevent. 
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4.4  TYPES  AND  SUBTYPES 

In  the  Ada  language  certain  types  and  subtypes  may  be  declared  in  more  than 
one  way.  For  instance,  the  following  sets  of  declarations  produce  equivalent 
subtypes: 


type  CONSTRAINED_AR  is  array  (INTEGER  range  1  ..  10)  of  BOOLEAN; 
type  INDEX  is  INTEGER  range  1  ..  10; 

type  UNCONSTRAINED_AR  is  array  (INDEX  range  <>)  of  BOOLEAN; 
subtype  CONSTRAINED_AR  is  UNCONSTRAINED_AR  (INDEX); 


the  only  difference  being  that  the  base  type  and  index  subtype  corresponding  to 
the  first  declaration  are  anonymous.  In  order  to  reconstruct  the  source  text  it 
is  necessary  that  the  syntax  of  the  declarations  be  recorded;  however,  semantic 
processing  would  be  facilitated  if  the  same  representation  were  used  for 
C0NSTRAI‘NE0_AR  regardless  of  which  set  of  declarations  produced  it.  In  order  to 
satisfy  both  needs  DIANA  has  two  classes  associated  with  types  and  subtypes. 

The  class  TYPE_DEF  records  syntax.  The  nodes  belonging  to  this  class  are 
not  intended  to  be  used  for  semantic  processing,  hence  they  have  no  semantic 
attributes,  and  are  never  designated  by  any  kind  of  attribute  other  tnan  a 
structural  attribute.  A  TYPE_DEF  node  may  correspond  to: 

(a)  a  subtype  indication 

(b)  the  portion  of  a  type  declaration  following  the  reserved  word  "is' 

(c)  the  type  of  an  object  as  given  in  an  object  declaration 


TYPE_DEF  is  subdivided  into  classes  according  to  syntactic  similarities  of 
the  source  text  which  the  nodes  represent.  The  class  structure  of  TYPE_DEF  has 
no  semantic  meaning. 

TYPE_DEF  contains  three  nodes  which  are  really  intermediate  nodes: 
integer_def,  float_def,  and  fixed  def.  The  syntax  of  a  numeric  type  definition 
consists  solely  of  a  range,  floating  point,  or  fixed  point  constraint. 
Unfortunately,  the  nodes  representing  these  constraints  are  already  members  of 
class  CONSTRAINT  --  to  include  them  in  TYPE_DEF  as  well  would  have  introduced 
multiple  class  memberships.  Instead,  three  new  nodes  were  introduced  inio 
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TYPE_0EF;  each  has  a  single  structural  attribute  denoting  the  actual  constraint. 

Class  TYPE_SPEC  is  the  complement  of  TYPE_DEF;  it  represents  the  Ada 
concept  of  types  and  subtypes.  The  nodes  comprising  TYPE_SPEC  are  compact 
representations  of  types  and  subtypes,  suitable  for  semantic  processing.  It  is 
not  necessary  to  traverse  a  lengthy  chain  of  nodes  in  order  to  obtain  all  of  the 
pertinent  information  concerning  the  type/subtype,  nor  are  special  cases  (i.e. 
different  structures)  introduced  by  irrelevant  syntactic  differences.  The  nodes 
comprising  class  TYPE_SPEC  do  not  record  source  text;  they  contain  semantic 
attributes  only,  and  are  not  accessible  through  structural  attributes. 

Because  the  TYPE_SPEC  nodes  are  not  designed  to  record  source  code,  but  are 
intended  to  represent  the  coricept  of  types  and  subtypes,  there  is  not 
necessarily  a  one-to-one  correspondence  between  the  types  and  subtypes  declared 
in  the  source  and  the  TYPE_SPEC  nodes  included  in  the  DIANA  tree.  An 
implementation  must  represent  each  of  the  universal  types  (which  cannot  be 
explicitly  declared  in  an  Ada  program),  and  additional  nodes  may  be  created  to 
represent  various  anonymous  types  (to  be  described  later).  Consequently,  it  is 
not  possibly  to  store  the  type  specification  information  within  the  nodes 
denoting  defining  occurrences  of  types  and  subtypes.  Thus  the  type  id  and 
subtype_id  nodes  of  class  DEF_NAME  represent  the  NAMES  of  types  and  subtypes, 
not  the  types  and  subtypes  themselves.  Access  to  the  corresponding  type 
specification  is  provided  by  means  of  the  sm  type  spec  attribute. 

The  construction  of  new  TYPE__SPEC  nodes  for  a  DIANA  tree  is  governed  by  two 
basic  principles: 

1.  Each  distinct  type  or  subtype  is  represented  by  a  distinct  node  from 
class  TYPE_SPEC. 

2.  There  are  never  two  TYPE  SPEC  nodes  for  the  same  type  or  subtype 


These  principles  ensure  that  the  only  action  needed  to  determine  whether  or 
not  two  entities  have  the  same  subtype  or  the  same  base  type  is  the  comparison 
of  the  associated  TYPE_SPEC  nodes.  If  both  denote  the  same  node  (not  equivalent 
nodes,  but  the  SAME  node)  then  the  types  are  the  same;  if  they  reference 
different  nodes  then  the  types  are  not  the  same. 

Since  a  type  definition  always  creates  a  new  type,  a  new  TYPE_SPEC  noce  's 
created  for  every  type  definition.  This  is  not  necessarily  true  for  suptype 
declarations.  If  a  subtype  declaration  does  not  include  a  constraint  then  it 
does  not  introduce  a  new  subtype  (it  in  effect  renames  the  subtype  denoted  by 
the  type  mark),  therefore  a  new  TYPE_SPEC  node  is  not  introduced.  In  this  case 
the  sm  type  spec  attribute  of  the  subtype_1d  denotes  the  TYPE_SPEC  node 
associated  wTth  the  type  mark. 

All  anonymous  types  described  in  the  Ada  Reference  Manual  are  represented 
in  DIANA;  i .e. 

(a)  anonymous  derived  types  created  by  numeric  type  definitions  [ARM, 
sections  3.5.4,  3.5.7,  and  3.5.9] 
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The  nodes  representing  constrained  types  have  an  additional  attribute, 
sm  depends  on  dscrmt,  which  indicates  whether  or  not  the  component  subtype 
depends  on  a  discriminant.  A  subtype  of  a  record  component  depends  on  a 
discriminant  if  it  has  a  constraint  which  contains  a  reference  to  a  discriminant 
of  the  enclosing  record  type.  Within  a  record  type  definition,  the  only  forms 
of  constraints  which  can  contain  a  reference  to  a  discriminant  are  index  and 
discriminant  constraints.  Since  the  only  nodes  for  which  this  attribute  could 
ever  be  true  are  the  constrained_array,  constrained_record,  and 
constrained  access  nodes,  it  was  not  necessary  to  define  an  sm  depends  on  dscrmt 
attribute  for  any  other  TYPE_SPEC  nodes  (although  a  component  subtype  may  be  a 
private  type  with  a  discriminant  constraint,  such  a  subtype  is  represented  by  a 
constrained  record  node  rather  than  a  PRIVATE  SPEC  node,  as  discussed  in  section 
4.4.4). 

The  sm  depends  on  dscrmt  attribute  was  defined  because  otherwise  it  would 
not  be  easy  to  determine  whether  or  not  a  component  subtype  depended  on  a 
discriminant  if  the  constraint  were  sufficiently  complicated.  This  information 
is  essential  because  at  certain  times  a  component  subtype  that  depends  on  a 
discriminant  is  treated  differently  from  one  that  does  not.  For  instance,  the 
elaboration  time  of  a  component  subtype  is  determined  by  whether  or  not  it 
depends  on  a  discriminant.  If  the  component  subtype  does  not  depend  on  a 
discriminant  then  it  is  elaborated  when  the  enclosing  record  type  is  elaborated; 
otherwise  the  component  subtype  is  not  fully  elaborated  until  a  discriminant 
constraint  is  imposed  on  the  enclosing  record  type  (the  expressions  in  the 
component  subtype  indication  which  are  not  discriminants  are  evaluated  during 
the  elaboration  of  the  enclosing  record  type). 


4.4.2  UNIVERSAL  TYPES 

The  Ada  programming  language  defines  three  universal  types  --  universal 
integer,  universal  real,  and  universal  fixed.  The  TYPE_SPEC  nodes  for  tne 
universal  types  have  no  attributes  of  their  own  since  their  properties  are  fixed 
--  they  are  not  implementation  dependent,  nor  can  they  be  declared  by  a  user. 
For  example,  there  is  no  need  for  the  sm  is  anonymous  attribute  because 
universal  types  are  always  anonymous.  The  universal  types  are  used  as  the  types 
of  named  numbers  and  certain  static  expressions. 


4.4.3  DERIVED  TYPES 

All  types  other  than  the  universal  types  may  be  derived,  although 
restrictions  may  be  placed  on  the  location  of  certain  kinds  of  derived  type 
definitions.  For  instance,  a  derived  type  definition  involving  a  private  type 
is  not  allowed  within  the  package  specification  declaring  that  private  type 
[ARM,  7.4.1];  however,  that  private  type  may  be  derived  outside  of  the  package 
specification.  Hence  the  attribute  sm  derived  is  defined  for  class 
DERIVABLE_SPEC.  If  a  type  is  derived  then  sm  derived  references  the  TYPE  SPEC 
node  of  the  parent  type  (not  the  parent  subtype);  otherwise  the  attribute  is 
void. 
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A  derived  type  definition  creates  a  new  base  type  whose  properties  are 
derived  from  the  parent  type.  In  addition,  it  defines  a  subtype  of  the  derived 
type.  A  derived  type  definition  in  DIANA  always  results  in  the  creation  of  a 
new  TYPE_^SPEC  node  for  the  new  base  type.  Since  its  characteristics  are  derived 
from  the”parent  type  it  will  need  the  same  kinds  of  attributes  in  order  to 
represent  the  appropriate  values,  thus  the  base  type  is  represented  by  the  same 
kind  of  node  as  the  parent  type. 

If  the  parent  type  and  the  parent  subtype  of  a  derived  type  do  not  have  the 
same  constraints,  then  a  new  TYPE_SPEC  node  is  created  for  the  subtype  of  the 
derived  type.  This  node  will  record~the  new  constraint,  and  its  base  type  will 
be  the  newly  created  base  type.  The  name  of  the  derived  type  will  denote  this 
subtype,  hence  all  references  to  the  derived  type  will  denote  the  type 
specification  of  the  subtype.  As  a  result,  the  base  type  is  anonymous. 

If  the  base  type  is  a  record  or  enumeration  type  then  a  representation 
clause  may  be  given  for  the  derived  type  if  a  representation  clause  was  not 
given  for  the  parent  type  BEFORE  the  derived  type  definition.  Hence  it  is 
possible  for  the  derived  type  to  have  a  different  representation  from  that  of 
the  parent  type.  The  information  given  in  an  enumeration  representation  clause 
is  recorded  in  the  nodes  for  the  literals  of  the  enumeration  type;  the 
information  from  the  component  clauses  is  encoded  in  the  nodes  for  the 
components  (including  discriminants)  of  the  record  type.  Due  to  the  possibility 
of  different  representations,  it  is  not  always  feasible  for  the  derived  type  to 
share  the  enumeration  literals  or  record  components  of  the  parent  type. 

DIANA  requires  that  copies  be  made  of  the  defining  occurrences  of  the 
enumeration  literals,  unless  the  parent  type  is  a  generic  formal  discrete  type, 
which  does  not  have  any  literals.  The  new  literals  reference  the  derived  type 
as  the  type  to  which  they  belong,  but  have  the  same  position  number  as  the 
corresponding  original  literals.  If  a  representation  clause  is  not  given  for 
the  derived  type  then  the  sm  rep  attribute  will  also  have  the  same  value.  The 
node  for  the  derived  type  denotes  these  new  defining  occurrences  as  its 
literals.  Duplication  has  an  additional  advantage  for  enumeration  |•:*erals  -- 
since  the  literal  of  the  derived  type  overloads  the  corresponding  literal  of  the 
parent  type,  it  is  convenient  to  have  two  different  defining  occurrences  when 
processing  used  occurrences  of  the  literals. 

DIANA  also  requires  the  duplication  of  the  discrimina''t  oa'^*  and  f'e 
comoonent  list  for  a  derived  record  type  if  a  representation  clause  is  qiven  ^^or 
that  type.  If  an  implementation  determines  that  no  such  clause  is  given,  it  can 
choose  whether  to  copy  the  defining  occurrences  or  reference  the  structure  of 
the  parent  type.  Because  the  defining  occurrences  do  not  reference  the  record 
type  to  which  they  belong,  no  inconsistencies  are  introduced  if  the  structure  is 
not  copied  when  the  representation  does  not  change. 


4.4.4  PRIVATE,  LIMITED  PRIVATE,  AND  LIMITED  TYPES 

A  private  type  declaration  separates  the  properties  of  the  type  that  may  be 
used  outside  of  the  package  from  those  which  are  hidden  from  the  user,  A 
private  type  has  two  points  of  declaration  --  the  first  declaration  is  the 
private  one,  occurring  in  the  visible  part  of  the  package  specification;  the 
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second  is  a  full  type  declaration  that  appears  in  the  private  part  of  the 
package.  Private  and  limited  private  types  are  represented  by  nodes  from 
PRIVATE  SPEC,  and  complete  type  specifications  by  those  belonging  to 

full_tyPe_spec. 

A  (limited)  private  declaration  introduces  a  private  or  l_private  node,  and 
the  subsequent  full  type  declaration  introduces  the  appropriate  node  from  class 
FULL  TYPE_SPEC.  The  (limited)  private  specification  rather  than  the  full  type 
specification  is  referenced  as  the  type  of  an  object,  expression,  etc.  In 
addition,  all  used  occurrences  of  the  type  name  will  denote  the  type_id  of  the 
private  declaration.  The  PRIVATE_SPEC  nodes  have  an  sm  type  spec  attribute  that 
provides  access  to  the  full  type  specification.  In  this  way  the  distinction 
between  private  and  full  types  is  preserved  for  the  kinds  of  semantic  processing 
which  require  knowledge  of  whether  or  not  a  type  is  private,  but  the  information 
recorded  in  the  full  type  specification  is  available  for  the  processing  which 
needs  it. 

The  specification  of  a  (limited)  private  type  may  be  viewed  as  being 
distributed  over  two  nodes,  rather  than  being  represented  by  two  different 
nodes.  The  full  type  specification  can  never  be  referenced  as  the  type  of  an 
object,  expression,  etc.,  hence  the  principle  that  there  are  never  two  TYPE  SPEC 
nodes  for  the  same  type  or  subtype  is  not  violated  by  this  representation  of 
(limited)  private  types. 

An  alternate  solution  was  considered.  It  was  proposed  that  all  references 
to  the  (limited)  private  type  occurring  either  outside  of  the  package  or  within 
the  visible  part  of  the  package  denote  the  PRIVATE_SPEC  node,  and  those 
references  occurring  within  either  the  private  part  of  the  package  or  the 
package  body  denote  the  FULL_TYPE_^SPEC  node.  Although  there  would  be  two 
TYPE_SPEC  nodes  for  one  type,  within  a  given  area  (the  two  areas  being  the  one 
in  which  the  type  structure  is  hidden  and  the  one  in  which  the  type  structure  is 
visible)  it  would  appear  as  if  there  were  only  one  node.  With  this  approach  the 
uses  of  the  type  would  reflect  whether  or  not  the  structure  of  the  type  was 
visible  at  that  point  in  the  source  code.  Unfortunately,  upon  closer 
examination  the  previous  assumptions  proved  to  be  untrue. 

Consider  the  case  of  a  subprogram  declared  in  the  visible  part  of  a 
package.  Suppose  the  subprogram  has  a  parameter  of  a  private  type  that  is 
declared  in  the  visible  part  of  the  same  package.  Although  it  is  possible  for 
the  parameter  in  the  suborogram  declaration  to  denote  the  private  specification 
as  its  type,  and  the  parameter  in  the  subprogram  body  declaration  to  denote  the 
full  type  specification  as  its  type,  ALL  references  to  both  the  subprogram  and 
its  parameters  denote  the  first  defining  occurrences  --  those  in  the  package 
specification,  which  reference  the  private  specification.  Suppose  an  object  of 
the  private  type  were  declared  inside  the  subprogram  body;  it  would  refer  to  the 
full  type  specification  as  its  type.  The  subprogram  body  would  then  contain  a 
mixture  of  references  to  the  private  type  --  some  to  the  full  type 
specification,  others  to  the  private  specification.  It  would  no  longer  be 
possible  to  simply  compare  TYPE_SPEC  nodes  to  determine  it  two  entities  have  the 
same  type.  As  a  consequence,  this  solution  was  rejected. 

The  private  and  l_private  nodes  always  represent  base  types.  Although  a 
subtype  of  a  (limited)  private  type  may  be  introduced,  it  will  be  rep’'esented  by 
a  node  from  class  FULL  TYPE  SPEC  rather  than  one  from  PRIVATE  SPEC.  Due  to  the 
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restrictions  placed  on  the  creation  of  new  TYPE  SPEC  nodes,  a  new  node  may  be 
created  for  such  a  subtype  only  -if  a  new  constraini  is  imposed  upon  it  (in  other 
words,  the  subtype  is  not  a  renaming  of  another  type  or  subtype). 

The  kinds  of  constraints  which  may  be  imposed  upon  a  (limited)  private  type 
are  restricted  in  those  regions  where  the  full  structure  of  the  type  is  hidden. 
The  structure  (and  therefore  the  class)  of  a  private  or  limited  private  type 
without  discriminants  is  not  visible  outside  of  the  package  or  in  the  visible 
part  of  the  package,  therefore  no  new  constraints  may  be  imposed  on  such  types 
in  these  regions.  If  a  private  type  has  discriminants  then  its  full  type  must 
be  a  record  type,  and  a  discriminant  constraint  is  permitted  even  in  the 
locations  where  the  structure  of  the  rest  of  the  record  is  unknown.  That 
subtype  is  represented  by  a  constrained_record  node.  If  the  declaration  occurs 
within  the  private  part  of  the  package  or  the  package  body  then  the  structure  of 
the  private  type  is  visible,  and  the  subtype  is  represented  by  the  appropriate 
node  from  class  FULL_TYPE_SPEC. 

The  1_private  node  represents  types  which  are  limited  private,  not  types 
which  are”limited.  Types  which  are  limited  include  task  types,  composite  types 
having  a  subcomponent  which  is  limited,  and  types  derived  from  a  limited  type. 
Because  these  types  are  not  explicitly  declared  to  be  limited,  they  are  not 
represented  by  a  distinct  node  kind  as  the  limited  private  types  are  (to  do  so 
would  require  semantic  analysis  to  determine  when  the  distinct  node  kind  was 
appropriate).  Instead,  an  additional  attribute  is  defined  where  necessary. 

Task  types  are  always  limited,  hence  there  is  no  need  to  record  that 
information  in  the  form  of  an  additional  attribute.  This  is  not  true  for  arrays 
and  records.  Determining  whether  or  not  an  array  or  record  has  any  limited 
subcomponents  could  be  a  very  time-consuming  process  if  the  structure  of  the 
composite  type  Is  very  complicated.  As  a  consequence,  the  sm  is  limited 
attribute  was  defined  for  the  class  UNCONSTRAINED_COMPOSITE.  It  has  a  boolean 
value  indicating  whether  or  not  the  type  is  limited?  Since  derived  tyoes  are 
represented  by  the  same  kind  of  nodes  as  their  parent  types,  the  fact  that  a 
derived  type  is  limited  can  be  recorded  in  same  way  that  it  was  recorded  for  the 
parent  type. 

On  the  surface  it  may  seem  that  a  problem  similar  to  that  discussed  for 
composite  types  having  limited  components  exists  for  composite  types  having 
private  components.  A  composite  type  that  *^as  private  subcomponents  and  -s 
declared  outside  of  the  package  containing  the  private  type  de^inifion  has 
certain  restrictions  placed  on  the  operations  allowed  for  the  composite  type. 
The  only  operations  permitted  are  those  which  are  dependent  on  tne 
characteristics  of  the  private  declaration  alone  (see  section  7.4.2  of  the  Ada 
Reference  Manual). 

A  closer  examination  reveals  that  at  most  it  is  necessary  to  check  a 
component  type  (as  opposed  to  component  types  and  subcomponent  types)  to 
determine  if  an  operation  is  legal  or  not.  The  operations  allowed  for  types 
which  are  composites  of  composites  are  also  allowed  for  composite  types  with 
private  components  (assignment,  aggregates,  catenation,  etc.).  Operations 
involving  the  private  component  rather  than  the  composite  type  as  a  whole  may  be 
restricted;  for  instance,  a  selected  component  involving  a  component  of  the 
private  component  is  not  allowed.  Since  the  type  of  the  private  componert  is 
determined  during  type  resolution  of  the  sub-expression,  no  lengthy  searches  are 
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required  to  determine  that  the  component  is  private.  Certain  operations  that 
are  a'lov^ed  for  arrays  of  non-composite  objects,  such  as  the  relational 
operators  for  arrays  of  scalar  components  and  the  logical  operators  for  arrays 
of  boolean  components,  would  not  be  allowed  under  the  circumstances  described 
above  because  it  would  not  be  possible  to  determine  if  the  component  type  were 
indeed  a  scalar  type  or  a  boolean  type.  However,  such  a  check  involves  only  a 
single  component  type. 

A  need  could  not  be  found  for  an  attribute  indicating  that  an  array  or 
record  has  private  subcomponents;  hence  none  was  defined. 


4.4.5  INCOMPLETE  TYPES 

An  incomplete  type  definition  allows  the  definition  of  "mutually  dependent 
and  recursive  access  types"  [ARM,  3.8.1].  Like  a  private  type,  it  has  two 
points  of  definition:  one  for  the  incomplete  type,  and  a  second  for  the  full 
type  specification. 

Although  the  uses  of  the  name  of  an  incomplete  type  are  restricted  when 
they  occur  before  the  end  of  the  subsequent  full  type  declaration  (the  name  may 
appear  only  in  the  subtype  indication  of  an  access  type  definition),  the 
incomplete  type  becomes  an  ordinary  full  type  once  its  structure  has  been  given. 
Since  there  is  no  need  to  distinguish  the  incomplete  type  from  a  full  type  once 
the  structure  of  the  full  type  is  known,  the  solution  adopted  for  private  types 
is  not  appropriate  for  incomplete  types.  In  general,  incomplete  types  are  not 
represented  as  such  in  DIANA;  their  full  type  specifications  are  represented  by 
nodes  from  class  FULL_TYPE  SPEC,  and  attributes  denoting  the  incomplete  type 
actually  reference  the  full  type  specification. 

Only  one  sort  of  incomplete  type  is  represented  by  a  distinct  node  in  the 
DIANA  tree.  Included  in  the  class  TYPE_SPEC  is  the  node  incomplete,  which  was 
introduced  to  handle  an  anomoly  in  the  Ada  programming  language.  The  language 
places  the  following  restrictions  on  the  placement  of  the  full  type  declaration; 

"If  the  incomplete  type  declaration  occurs  immediately  within  either  a 
declarative  part  or  the  visible  part  of  a  package  specification,  then  the  full 
type  declaration  must  occur  later  and  immediately  within  the  same  declarative 
part  or  visible  part.  If  the  incomolete  tyoe  declarator  occurs  immediately 
within  the  private  part  of  a  package,  then  the  full  type  aeclaration  must  occur 
later  and  immediately  within  either  the  private  part  itself,  or  the  declarative 
part  of  the  corresponding  package  body."  [ARM,  3.8.1] 

Because  a  package  body  may  be  in  a  separate  compilation  unit,  it  is 
possible  for  the  full  type  specification  of  an  incomplete  type  declared  in  the 
private  part  of  a  package  to  be  in  a  separate  compilation  unit.  In  this  case  it 
is  not  possible  for  refe-ences  to  the  incomplete  type  which  occur  in  the  packa-e 
specification  to  denote  the  full  type  specification;  DIANA  forbids  forward 
references  of  that  sort.  It  was  necessa-^y  to  define  a  node  to  represent  the 
incomplete  type  in  this  special  case,  hence  the  incomplete  node  was  introduced. 
It  has  a  single  attribute,  sm  discriminant  s,  to  represent  any  discriminants 
belonging  to  the  incomplete  type.~  If  the  full~type  specification  is  not  in  a 
different  compilation  unit  the  incomplete  node  is  not  used  to  represent  the 
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Incomplete  type. 

This  problem  does  not  arise  for  private  types.  The  Ada  language  requires 
that  the  full  type  specification  of  a  private  type  be  given  in  the  private  part 
of  the  package  specification,  thus  it  may  never  occur  in  a  separate  compilation 
unit. 


DIAHA  does  not  specify  the  manner  in  which  the  full  type  specification  may 
be  accessed  from  the  incomplete  type  specification  in  this  special  case  --  to  do 
so  would  impose  restrictions  on  an  implementation.  All  references  tu  the 
specification  of  this  incomplete  type  will  reference  the  Incomplete  node,  even 
those  occurring  after  the  full  type  declaration.  Since  an  implementation  must 
provide  some  solution  to  the  problem  of  reaching  the  full  type  specification  for 
references  to  the  incomplete  type  occurring  within  the  package  specification, 
there  seemed  to  be  no  reason  to  deviate  from  the  DIANA  requirerr.ent  that  all 
references  to  a  part  cular  entity  denote  the  same  node. 

It  should  be  noted  that  it  is  possible  to  reach  the  incomplete  type 
specification  from  the  subsequent  full  type  declaration.  The  sm  first  attribute 
of  the  type  id  introduced  by  the  full  type  declaration  denotes  the  type  id  of 
the  incomplete  type  declaration.  Both  type_id  nodes  have  an  sm  type  spec 
attribute  denoting  their  respective  type  specifications. 


4.4.6  GENERIC  FORMAL  TYPES 

Although  "a  generic  formal  type  denotes  the  subtype  supplied  as  the 
corresponding  actual  parameter  in  a  generic  instantiation"  [ARM,  12.1.2],  a 
generic  formal  type  is  viewed  as  being  unique  within  the  generi'c  unit.  Hence  a 
new  TYPE_SPEC  node  is  introduced  by  each  generic  type  declaration,  and  the 
attributes  of  the  node  are  set  as  if  the  generic  type  were  a  new  type. 

A  generic  formal  type  is  represented  by  the  DERIVABLE  SPEC  node  that  ■’s 
appropriate  for  its  kind.  The  values  of  the  attributes  are  set  in  a  manner 
which  reflects  the  properties  of  the  generic  type  within  the  generic  unit.  For 
instance,  sm  base  type  contains  a  self-reference,  sm  derived  is  void,  and 
sm  is  anonymous  is  false,  regardless  of  the  whether  or  not  any  of  the  actual 
subtypes  have  the  same  attribute  values.  A  representation  specification  cannot 
be  given  for  a  generic  formal  type;  th’s  restriction  is  reflected  in  tne  values 
of  all  attributes  which  record  representation  information  (sm  size  is  void, 
sm_1s_packed  is  false,  etc.). 

Some  of  the  attributes  of  a  node  representing  a  generic  formal  type  may  be 
undefined  because  they  require  knowledge  of  the  actual  subtype.  Since  there  may 
be  numerous  instantiations  it  is  not  possible  to  set  these  attributes  in  the 
node  representing  the  generic  type.  For  example,  a  generic  formal  discrete  type 
is  represented  by  an  enumeration  node;  the  attributes  sm  literal  s  and  sm  -gnqe 
are  not  defined  because  they  depend  on  the  actual  subtype.  The  information 
recorded  by  such  attributes  is  not  necessary  ^or  the  semantic  processing  of  the 
generic  type  within  the  generic  unit. 
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The  TYPE  SPEC  nodes  corresponding  to  generic  formal  types  cot'tain  no 
indication  tKat  they  are  indeed  generic  formal  types.  This  information  can  be 
deduced  from  the  context  of  the  declarations  and  recorded  by  an  implementation 
in  whatever  manner  it  finds  to  be  most  convenient. 


4.4.7  REPRESENTATION  INFORMATION 

Representation  specifications  can  be  given  for  certain  types  and  first 
named  subtypes  through  pragmas  and  representation  clauses.  Although  occurrences 
of  these  pragmas  and  representation  clauses  remain  in  the  DIANA  tree  to  enable 
the  source  to  be  reconstructed,  they  are  additionally  recorded  with  the 
TYPE_SPEC  nodes  corresponding  to  the  type  structures  that  they  affect. 

The  occurrences  of  the  language  pragmas  PACK  and  CONTROLLED  are  recorded 
with  the  attributes  sm  is  packed  (for  array  and  record  types)  and 
sm  is  controlled  (for  accesstypes) . 

A  representation  clause  may  be  given  for  a  record  type,  giving  storage 
information  for  the  record  itself  and/or  its  components;  a  reference  to  this 
specification  is  recorded  in  the  semantic  attributes  of  the  TYPE_SPEC  node 
representing  the  record  type  a.s  well  as  the  defining  occurrences  of  the 
discriminants  and  components.  Similarly  for  enumeration  types,  information  from 
representation  specifications  for  the  enumeration  literals  is  recorded  with  the 
defining  occurrences  of  the  enumeration  literals. 

Length  clauses  may  be  applied  to  various  types.  The  presence  of  a  length 
clause  specifying  the  storage  size  for  a  task  or  access  type  is  recorded  with 
the  sm  storage  size  attribute.  A  length  clause  may  also  be  used  to  place  a 
limit  on  the  number  of  bits  allocated  for  objects  of  a  particular  type  or  first 
named  subtype.  A  size  specification  is  indicated  by  one  of  two  different 
attributes,  depending  on  the  kind  of  type  a  particular  node  represents.  The 
TYPE_SPEC  nodes  representing  non-scalar  types  have  an  sm  size  attribute  which  is 
of  type  EXP;  it  references  the  actual  expression  given  in  the  length  clause,  and 
is  void  if  no  length  clause  is  given. 

TYPE_SPEC  nodes  for  scalar  types  have  a  cd  impl  size  attribute,  which  is  of 
the  private  type  value.  Unlike  the  attributes  corresponding  to  other  kinds  c' 
representation  clauses,  cd  impl  size  does  not  necessarily  contain  the  value 
given  in  a  length  clause.  It  was  introduced  to  facilitate  the  evaluation  of 
static  expressions.  DIANA  always  records  the  value  of  static  expressions; 
however,  the  static  values,  of  certain  Ada  attributes  are  implementation 
dependent.  Since  these  attributes  are  related  to  static  types,  it  is  convenient 
to  store  this  information  with  the  node  representing  the  type. 

One  such  attribute  is  SIZE,  which  returns  the  actual  number  of  bits 
required  to  store  any  object  of  that  type.  The  value  of  this  attribute  is 
recorded  with  the  cd  impl  size  attribute,  which  has  a  value  even  if  no  length 
clause  is  given  for  the  type.  A  length  clause  merely  specifies  the  upper  bound 
for  the  size  of  objects  of  that  type,  hence  it  is  possible  for  the  value  of 
cd  impl  size  to  be  smaller  than  that  given  in  a  length  clause.  Because  the  Ada 
programming  language  restricts  static  types  to  the  scalar  types,  this 
implementation  dependent  attribute  is  not  necessary  for  the  nodes  representing 
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non-scalar  types. 

The  other  implementation  dependent  attribute  defined  in  DIANA  is  the 
cd  imp!  small  attribute  for  nodes  representing  fixed  point  types.  It  contains 
the  value  to  be  returned  for  the  Ada  attribute  SMALL.  The  user  may  specify  in  a 
length  clause  a  value  for  “small"  (the  smallest  positive  model  number  for  the 
type  or  first  named  subtype);  this  value  is  used  in  representing  values  of  that 
fixed  point  type,  and  may  affect  storage  requirements  for  objects  of  that  type. 
If  no  length  clause  is  given,  then  cd  impl  smal 1  will  contain  the  value  fo’' 
"small"  selected  by  the  implementation;  Tn  this  case  "small"  for  the  base  type 
may  differ  from  "small"  for  subtypes  of  that  base  type  [ARM,  3.5.9]. 


Section  4.5 


CONSTRAINTS 


4.5  CONSTRAINTS 

The  Ada  programming  language  defines  five  kinds  of  constraints:  range, 
floating  point,  fixed  point,  index,  and  discriminant.  Because  constraints  are 
generally  imposed  on  types  or  subtypes,  DIANA  handles  constraints  in  a  manner 
that  is  similar  to  the  way  in  which  types  and  subtypes  are  treated. 

There  are  both  syntactic  and  semantic  representations  of  certain 
constraints  in  DIANA.  However,  the  differences  between  the  two  are  not  as 
rigidly  observed  for  constraints  as  for  types  and  subtypes.  This  is  due  to  an 
effort  to  reduce  the  number  of  nodes  in  the  DIANA  tree,  and  to  the  fact  that  in 
many  cases  the  syntactic  representation  of  a  constraint  is  also  suitable  for 
semantic  processing. 

As  a  result,  there  are  not.  two  distinct  classes  for  representing 
constraints.  In  general,  the  class  CONSTRAINT  represents  the  syntax  of  the 
various  constraints;  there  is  no  class  defined  to  represent  a  semantic  version 
of  a  constraint.  Although  certain  TYPE_SPEC  nodes  (which  represent  the  semantic 
concept  of  a  type  or  subtype)  define  an”attribute  to  denote  a  constraint,  if  a 
node  from  class  CONSTRAINT  is-  appropriate  then  it  is  referenced  rather  than 
requiring  a  new  "semantic"  structure  to  be  built. 

To  facilitate  the  process  of  constraint  checking,  an  effort  was  made  to 
represent  the  constraints  in  DIANA  in  as  consistent  a  manner  as  possible.  The 
CONSTRAINT  node  is  not  always  suitable  for  the  following  kinds  of  constraints: 
discriminant,  floating  point,  fixed  point,  and  index. 

A  discriminant  constraint  is  a  series  of  discriminant  associations.  The 
sequence  of  associations  may  contain  a  mixture  of  EXP  and  assoc  nodes  (i.e. 
expressions  and  named  associations);  if  named  associations  are  used  then  the 
associations  do  not  even  have  to  appear  in  the  order  in  which  the  discriminants 
are  declared.  Thus  an  additional  sequence,  designated  by  the 
sm  normalized  dscrmt  s  attribute  of  the  constrained_record  node,  is  created  for 
a  discriminant  constraint.  This  sequence  is  a  normalized  version  of  the 
syntactic  sequence  --  all  named  associations  are  replaced  by  the  associated 
expressions,  in  the  order  in  which  the  corresponding  discriminants  are  declared. 
In  the  interest  of  economy,  if  the  discriminant  constraint  appears  in  the  source 
text  in  the  normalized  form,  then  the  record  subtype  specification  may  reference 
the  same  sequence  of  expressions  that  the  discriminant  constraint  denotes. 

A  different  problem  arises  for  fixed  or  floating  point  constraints  in 
TYPE_SPEC  nodes.  A  type  specification  in  DIANA  records  the  applicable 
constraint.  Because  a  fixed  or  floating  point  constraint  contains  two  parts. 
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either  of  which  is  optional  in  a  subtype  declaration,  it  is  possible  for  the 
accuracy  definition  and  the  range  constraint  to  be  given  in  two  different 
constraints.  Thus  it  is  not  sufficient  for  a  REAL  node  to  reference  a 
REAL_COHSTRAIMT  node.  Instead,  the  accuracy  definition  and  the  range  constraint 
are  recorded  by  separate  attributes  (sm  accuracy  and  smranqe)  in  the  REAL  node. 
Though  the  type  specification  does  not  reference  a  REAL^CONStrAINT  node,  it  may 
possibly  reference  one  or  both  of  the  constituents  of  a”REAL_CONSTRAINT  node. 

The  final  kind  of  constraint  to  have  an  additional  semantic  representation 
is  the  index  constraint.  DIANA  adheres  to  the  semantics  of  the  Ada  language  in 
its  representation  of  arrays  created  by  constrained  array  definitions.  An  index 
constraint  for  a  constrained_array  node  introduced  by  a  constrained  array 
definition  is  a  sequence  of  discrete  type  specifications;  if  an  index  subtype  is 
given  by  a  type  mark  then  the  type  specification  corresponding  to  the  type  mark 
appears  at  that  index  position.  Otherwise,  an  anonymous  subtype  is  created  for 
that  particular  index  position.  To  allow  array  subtypes  to  be  treated  in  a 
uniform  manner,  the  same  approach  is  taken  for  the  index  constraints  of  all 
constrained  array  subtypes  --  those  introduced  by  subtype  declarations,  slices, 
aggregates,  etc.  (some  of  these  may  be  anonymous).  The  new  sequence  is  denoted 
by  the  sm  index  sub  type  s  attribute  of  the  constrained_array  node. 

It  may  be  necessary  to  make  copies  of  some  constraints.  The  Ada 
programming  language  allows  multiple  object  declarations,  which  are  equivalent 
to  a  series  of  single  object  declarations.  If  the  multiple  object  declaration 
contains  a  constrained  array  definition  then  the  type  of  each  object  is  unique; 
if  the  declaration  contains  a  subtype  indication  with  a  constraint,  then  the 
subtype  of  each  object  is  unique.  In  either  case,  a  new  TYPE  SPEC  node  is 
created  for  each  object  in  the  identifier  list.  If  the  constraint  Is  non-static 
then  each  type  specification  has  a  unique  constraint.  Because  the  const-'  -nt 
designated  by  the  as  type  def  attribute  of  the  object  declaration  is  not 
designed  to  be  used  for  semantic  processing,  that  constraint  may  be  "shared" 
with  one  of  the  TYPE_SPEC  nodes. 

Due  to  structural  similarities,  the  class  RANGE  represents  both  an  Ada 
range  and  an  Ada  range  constraint.  The  difference  can  always  be  determined  from 
the  context.  If  the  RANGE  node  is  introduced  by  an  as  constraint  attribute,  as 
in  the  case  of  a  numeric  type  definition  or  a  subtype  indication,  then  it 
represents  a  range  constraint.  Otherwise,  it  is  a  simple  range  (i.e.  it  is 
introduced  by  a  loop  iteration  scheme,  a  membership  operato'-,  an  ent^y 
declaration,  a  choice,  or  a  slice).  A  RANGE  node  appearing  DIRECTLY  in  a 
sequence  of  DISCRETE_RANGE  nodes  (corresponding  to  an  index  constraint)  is  also 
a  simple  range. 

In  order  to  avoid  a  multiple  class  membership  for  the  class  RANGE,  which 
when  representing  a  range  constraint  should  belong  to  class  CONSTRAINT,  and  when 
denoting  a  simple  range  should  be  a  member  of  class  DISCRETE_RANGE ,  the  classes 
CONSTRAINT  and  DISCRETE_RANGE  were  merged.  Consequently,  CONSTRAINT  is  a 
combination  of  the  Ada  syntactic  categories  "constraint"  and  "discrete_range' . 
By  including  OISCRETE_RANGE  in  class  CONSTRAINT,  the  discrete_subtype  node  was 
introduced  into  the  class  representing  constraints.  It  was  therefore  necessary 
to  add  a  restriction  in  the  semantic  specification  of  DIANA  prohibiting  an 
attribute  having  the  type  CONSTRAINT  from  referencing  a  discrete_subtype  node. 
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Discrete  subtype  indications  are  represented  by  the  node  discrete_subtype. 
Although  discrete  subtype  indications  are  syntactically  identical  to  any  other 
kind  of  subtype  indication,  the  subtype_ Indication  node  could  not  be  included  in 
class  DISCRETE_RANGE  because  it  is  already  a  member  of  class  TYPE_0EF;  to  do  so 
would  have  introduced  multiple  membership  for  node  subtype_ indication.  Hence 
the  discrete_subtype  node  was  introduced.  It  has  an  as  subtype  indication 
attribute  which  denotes  the  actual  subtype  indication,  thus  discrete_subtype 
serves  as  an  intermediate  node. 

When  a  range  constraint,  a  floating  point  constraint,  or  a  fixed  point 
constraint  is  imposed  on  a  type  or  subtype,  it  is  necessary  to  perform 
constraint  checks  to  insure  that  the  constraint  is  compatible  with  the  subtype 
given  by  the  type  mark.  Unfortunately,  the  information  required  to  do  this  is 
not  incorporated  in  the  corresponding  type  specification.  Although  a  SCALAR 
node  does  have  an  sm  base  type  attribute,  it  does  not  necessarily  denote  the 
type  specification  corresponding  to  the  type  mark  in  the  subtype  indication  (a 
scalar  subtype  is  constructed  from  the  BASE  TYPE  of  the  type  mark,  not  the  type 
mark  itself). 

To  make  the  type  specification  corresponding  to  the  type  mark  accessible 
from  the  type  specification  of  the  new  subtype,  the  sm  type  spec  attribute  was 
defined  for  the  classes  RANGE  and  REAL_C0NSTRA1NT.  Although  a  range  constraint 
may  be  part  of  a  floating  point  or  fixed  point  constraint,  it  was  not  sufficient 
to  add  sm  type  spec  to  the  RANGE  node  alone;  the  accuracy  definition  must  be 
available  as  wel 1 .  The  definition  of  this  attribute  for  both  classes  results  in 
redundancy  for  the  range  constraints  which  are  part  of  fixed  or  floating  point 
constraints.  The  sm  type  spec  attributes  of  the  REAL__CONSTRAINT  node  and  the 
corresponding  RANGE  node  T^f  there  is  one)  always  "denote  the  same  type 
specification. 

If  the  constraints  are  associated  with  a  subtype  indication  then 
sm  type  spec  denotes  the  type  specification  of  the  type  mark;  however,  RANGE  and 
ftEAL]_CONSTRAINT  nodes  can  appear  in  other  contexts.  For  instance,  both  may 
appear  in  type  definitions.  The  expressions  for  the  bounds  of  a  range 
constraint  associated  with  a  type  definition  are  not  required  to  belong  to  the 
same  type,  therefore  it  is  not  feasible  for  sm  type  spec  to  reference  a 
previously  defined  type.  In  this  case  sm  type  spec  designates  the  type 
specification  of  the  new  base  type. 

RANGE  nodes  representing  (discretel  ranges  rathe'"  than  •■ange  constnaints 
can  appear  as  a  part  of  slices,  entry  family  declarations,  loop  iteration 
schemes,  membership  operators,  index  constraints,  and  choices.  In  each  of  these 
cases  the  bounds  must  be  of  the  same  type,  hence  sm  type  spec  denotes  the 
appropriate  base  type,  as  specified  in  the  Ada  Reference  Manual^  For  example, 
the  Ada  Reference  Manual  states  that  "for  a  membership  test  with  a  range,  the 
simple  expression  and  the  bounds  of  the  range  must  be  of  the  same  scalar  type" 
[ARM,  4.5.2];  therefore  sm  type  spec  for  a  RANGE  node  associated  with  a 
membership  operator  denotes  the  type  specification  of  that  scala'"  type. 

A  RANGE  attribute  is  represented  by  a  different  kind  of  node  from  the  other 
Ada  attributes.  Unlike  the  others  (except  for  BASE,  which  is  another  special 
case),  the  RANGE  attribute  does  not  return  an  expression;  thus  the  attributes 
sm  value  and  sm  exp  type  (defined  for  the  other  kinds  of  Ada  attributes)  do  not 
apply.  In  addition,  the  RANGE  attribute  does  not  appear  in  the  same  contexts  as 
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other  Ada  attributes.  Consequently  It  Is  represented  by 
range_attr1bute  node. 


a  special 
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4.6  EXPRESSIONS 

Expressions  In  a  DIANA  structure  are  represented  by  nodes  from  class  EXP. 
EXP  also  contains  the  class  NAME  because  certain  names  can  appear  in 
expressions. 

The  nodes  representing  expressions  record  both  the  syntax  and  the  semantics 
of  expressions;  therefore  nodes  in  this  class  contain  both  structural  and 
semantic  attributes,  and  may  be  denoted  by  both  structural  and  semantic 
attributes. 

There  are  two  kinds  of  expressions  which  have  a  syntactic  component  that 
may  vary:  the  membership  operator  may  contain  either  a  type  mark  or  a  range, 
and  the  allocator  may  contain  either  a  qualified  expression  or  a  subtype 
indication.  Unfortunately,  in  each  case  the  variants  do  not  belong  to  the  same 
DIANA  class,  therefore  a  single  attribute  could  not  be  defined  to  represent  the 
syntactic  component.  The  DIANA  solution  was  to  define  two  variants  for  each  of 
these  expressions,  each  variant  having  the  appropriate  structural  attribute  to 
record  the  syntax  of  that  particular  variant.  The  membership  operator  is 
represented  by  the  range_me'nbership  and  type^membership  nodes,  and  the  allocator 
is  represented' by  the  quil if 1ed_anocator  and  subtype_al locator  nodes. 

All  DIANA  nodes  representing  expressions  have  an  sm  exp  type  attribute;  it 
denotes  the  subtype  of  the  expression.  The  subtype  is  referenced  rather  than 
the  base  type  because  the  type  specification  of  the  subtype  contains  both  the 
applicable  constraint  AND  a  direct  path  to  the  specification  of  the  base  type. 
In  this  way,  all  nodes  representing  expressions  contain  the  information 
necessary  for  semantic  checking,  constraint  checking,  etc.  It  should  be  noted 
that  this  does  not  imply  that  sm  exp  type  can  never  denote  a  base  type  --  in  the 
Ada  programming  language  a  type  is  not  only  a  type,  but  an  unconstrained  subtype 
as  well. 

Some  expressions  can  have  static  values  (see  section  4.9  of  the  Ada 
Reference  Manual).  The  sm  value  attribute  was  defined  for  nodes  which  can 
represent  static  expressions  to  permit  the  static  value  to  be  obtained  without 
traversing  any  corresponding  subtrees.  If  the  value  of  an  expression 
represented  by  a  node  having  an  sm  value  attribute  is  not  static,  then  sm  value 
must  have  a  distinguished  value  indicating  that  it  is  not  evaluated. 

Due  to  syntactic  similarities,  various  nodes  in  class  EXP  can  represent 
entities  other  than  expressions.  The  selected  node  not  only  represents  selected 
components  of  records,  it  represents  expanded  names  as  well.  The  indexed  node 
represents  an  indexed  component;  however,  it  may  also  denote  a  member  of  an 
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entry  family.  These  nodes  have  the  attributes  sm  value  and  sm  exp  type  because 
they  can  represent  expressions;  however,  since  these  attributes  are  meaningless 
for  anything  other  than  an  expression,  they  are  undefined  if  the  node  does  not 
represent  an  expression  (an  expanded  name  denoting  an  object  or  a  literal  is 
considered  an  expression). 


4.6.1  EXPRESSIONS  WHICH  INTRODUCE  ANONYMOUS  SUBTYPES 

Certain  expressions  (such  as  slices)  impose  a  new  constraint  on  a  type.  To 
enable  the  subtypes  of  expressions  to  be  treated  in  a  consistent  manner,  DIANA 
requires  that  anonymous  subtypes  be  created  for  these  expressions.  The 
expressions  which  may  introduce  anonymous  subtypes  are  slices,  aggregates, 
string  literals,  and  allocators. 

Although  a  constraint  for  one  of  these  expressions  may  be  explicit,  it  is 
not  necessarily  different  from  an  existing  constraint.  In  the  interest  of 
efficiency,  DIANA  allows  an  existing  type  specification  to  be  referenced  as  the 
subtype  of  the  expression  if  can  be  STATICALLY  determined  that  the  constraints 
are  identical;  however,  an  implementation  is  free  to  create  an  anonymous  subtype 
for  each  such  expression  if  it  finds  that  approach  to  be  more  convenient.  For 
example,  if  it  can  be  determined  statically  that  a  slice  has  the  same  bounds  as 
the  array  prefix,  then  the  slice  node  is  allowed  (but  not  required)  to  denote 
the  type  specification  of  the  array  prefix  as  its  subtype.  If  it  can  be 
determined  statically  that  an  aggregate  or  string  literal  has  the  same 
constraints  as  the  context  type  (which  is  required  to  be  determinable  from  the 
context  alone)  then  the  type  specification  of  the  context  type  may  be  referenced 
as  the  subtype  of  the  expression. 

The  anonymous  subtype  is  constructed  from  the  appropriate  base  type  and  the 
new  constraint.  The  base  type  for  a  slice  is  obtained  from  the  array  prefix, 
and  the  constraint  is  the  discrete  range.  The  base  type  for  an  aggregate  or  a 
string  literal  is  taken  from  the  context;  determining  the  constraint  for  these 
expressions  is  more  complicated  (the  constraint  is  not  necessarily  explicit). 
Sections  4.2  and  4.3  of  the  Ada  Reference  Manual  discuss  this  procedure  in 
detail . 

An  allocator  containing  a  subtype  indication  with  an  explicit  constraint 
introduces  an  anonymous  subtyoe.  This  subtype  is  not  necessarily  that  of  the 
object  created  by  the  allocator  (for  further  details,  see  section  4.6.5); 
however,  a  new  type  specification  is  created  for  it  because  constraint  checks 
must  be  performed  to  ensure  that  the  constraint  is  compatible  with  the  type 
mark. 


Unlike  the  other  expressions  which  create  anonymous  subtypes,  the  allocator 
does  not  introduce  the  anonymous  subtype  via  the  sm  exp  type  attribute.  Though 
an  allocator  creates  a  new  object,  it  RETURNS  an  access  value.  The  anonymous 
subtype  is  not  the  subtype  of  the  access  value  returned  by  the  allocator,  hence 
it  cannot  be  denoted  by  sm  exp  type.  The  sm  desig  type  attribute  was  defined 
for  allocators  containing  subtype  indications;  it  denotes  the  type  specification 
corresponding  to  the  subtype  indication  (if  an  explicit  constraint  is  not  given 
then  sm  desig  type  references  the  type  specification  of  the  type  mark). 
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4.6.2  FUNCTION  CALLS  AND  OPERATORS 

The  Ada  programming  language  allows  operators  (both  predefined  and 
user-defined)  to  be  given  in  either  prefix  or  infix  form.  In  addition,  a 

function  can  be  renamed  as  an  operator,  and  an  operator  renamed  as  a  function. 
Consequently,  the  form  of  use  of  a  function  or  operator  implies  nothing  about 
whether  the  function  or  operator  is  predefined  or  user-defined.  Since  it  serves 
no  semantic  purpose  to  distinguish  function  calls  from  operators,  all  function 
calls  and  operators  are  represented  as  function  calls  in  a  DIANA  structure. 

There  are  two  exceptions  to  this  method  of  representation:  the 

short-circuit  operators  and  the  membership  operators.  These  operators  cannot  be 
represented  as  functions,  therefore  they  cannot  be  overloaded.  Unlike  the 
parameters  of  a  function  call,  all  of  which  are  evaluated  before  the  call  takes 
place,  the  evaluation  of  the  second  relation  of  a  short-circuit  operator  is 
dependent  upon  the  result  of  the  evaluation  of  the  first  relation.  The  second 
relation  is  not  evaluated  when  the  first  relation  of  an  "and  then"  operator  is 
"true"  or  when  the  first  relation  of  an  "or  else"  operator  is  "false".  A 

membership  operator  requires  either  a  type  mark  or  a  range,  neither  of  which  is 
an  expression,  hence  neither  can  be  represented  as  a  parameter.  These  operators 
are  represented  by  the  short_circuit  and  MEMBERSHIP  nodes  rather  than 
function_call  nodes. 

The  name  of  the  function  (a  used  occurrence)  provides  access  to  the 
defining  occurrence  of  the  function  or  operator,  making  it  possible  to  determine 
the  kind  of  function  or  operator  represented  by  the  function_cal 1 .  The 

lx  prefix  attribute  records  whether  the  call  is  given  in  prefix  or“infix  form; 

this  information  is  required  for  subprogram  specification  conformance  rules 
default  values  of  a  parameter  of  mode  "in"  might  be  a  function  call  or 
operator). 

The  subtype  of  a  function  call  is  considered  to  be  the  return  type.  If  the 
function  call  is  a  predefined  operator  then  the  return  type  is  the  appropriate 
base  type,  as  specified  in  section  4.5  of  the  Ada  Reference  Manual.  This  means 
that  the  subtypes  of  certain  function  calls  may  be  unconstrained;  for  example, 
the  result  of  a  catenation  is  always  of  an  unconstrained  array  subtype.  Since 
it  is  not  always  possible  to  determine  statically  the  constraints  on  a  value 
returned  by  a  function  call,  it  is  not  feasible  to  require  an  anonymous  subtype 
to  be  created  for  a  call  to  a  function  with  an  unconstrained  return  type. 


4.6.3  IMPLICIT  CONVERSIONS 

The  Ada  programming  language  defines  various  kinds  of  implicit  type 
conversions,  some  of  which  are  recorded  in  a  DIANA  structure,  while  others  are 
not. 


An  implicit  conversion  of  an  operand  of  a  universal  type  to  a  numeric  type 
may  be  required  for  an  operand  that  is  a  numeric  literal,  a  named  number,  or  an 
attribute.  Although  this  implicit  conversion  is  not  recorded  by  the 
introduction  of  a  distinct  node,  it  is  in  a  sense  recorded  by  the  value  of  the 
sm  exp  type  attribute.  If  the  context  requires  an  implicit  conversion  of  an 
operand  of  a  universal  type,  then  the  sm  exp  type  attribute  of  the 
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nuaeric  literal,  used_object_1d,  or  attribute  node  denotes  the  target  type 
rather  Than  the  universal  type. 

By  allowing  the  sm  exp  type  attribute  to  reflect  the  result  of  the  implicit 
conversion,  all  of  the  information  necessary  to  perform  the  conversion  is 
recorded  in  the  node  representing  the  literal,  named  number,  or  attribute;  no 
additional  context  information  is  required.  In  addition,  the  fact  that  an 
expression  is  the  operand  of  an  implicit  conversion  can  now  be  determined  easily 
by  a  DIANA  user.  For  instance,  a  numeric  literal  is  the  operand  of  an  implicit 
conversion  if  sm  exp  type  does  not  denote  a  universal  type.  If  sm  exp  type  did 
not  reflect  tRi  conversion,  then  in  any  context  in  which  an  operand  of  a 
universal  type  would  not  be  appropriate  it  would  be  necessary  to  check  for  the 
existence  of  a  convertible  universal  operand.  Since  scalar  operands  can  appear 
in  numerous  contexts  that  require  non-uni versal  types,  a  substantial  amount  of 
checking  would  be  involved.  The  DIANA  approach  localizes  the  checking  for  an 
implicit  conversion  to  the  nodes  which  may  represent  convertible  universal 
operands. 

The  semantics  of  the  Ada  language  force  the  determination  of  the  existence 
of  an  implicit  type  conversion  during  the  semantic  checking  phase  (an  implicit 
conversion  is  applied  only  if  the  innermost  complete  context  requires  the 
conversion  for  a  legal  interpretation);  recording  information  that  is  already 
available  should  not  impose  a  hardship  on  an  implementation.  The 
numeric_literal ,  used_object_id,  and  attribute  node  all  represent  used 
occurrences;  hence  no  conflicts  should  arise  as  a  result  of  this  representation 
of  implicit  conversions  (i.e.  the  sm  obj  type  attribute  of  the  number_id  still 
denotes  a  universal  type). 

As  a  result  of  the  DIANA  representation  of  implicit  conversions,  the  used 
occurrences  of  a  named  number  cannot  always  be  represented  by  a  single  node, 
since  the  sm  exp  type  attribute  of  the  used_object_id  may  reflect  an  implicit 
conversion.  However,  a  single  used  occurrence  having  a  particular  target  type 
may  represent  all  used  occurrences  of  that  named  number  requiring  that 
particular  type. 

If  the  variable  to  the  right  of  the  assignment  operator  in  an  assignment 
statement  is  an  array,  then  the  expression  to  the  right  of  the  assignment 
operator  is  implicitly  converted  to  the  subtype  of  the  array  variable.  This 
implicit  subtype  conversion  may  also  be  oe'^formed  on  the  initial  value  ’n  an 
array  variable  declaration.  Many  kinds  of  expressions  produce  anonymous  array 
subtypes,  which  have  a  DIANA  representation.  Since  this  representation  is 
introduced  by  the  sm  e  :p  type  attribute  of  the  corresponding  expression,  t^’e 
solution  adopted  for  scalar  operands  is  not  suitable  for  arrays.  Due  to  the 
fact  that  the  implicit  subtype  conversion  can  occur  only  in  two  well-defined 
contexts,  it  was  decided  that  it  was  not  necessary  to  record  the  need  for  an 
implicit  conversion. 

Certain  type  conversions  take  place  during  a  call  to  a  derived  suborogram. 
For  formal  parameters  of  the  parent  type  the  following  conversions  are 
performed:  the  actual  parameters  corresponding  to  parameters  of  mode  "in"  and 
"in  out"  are  converted  to  the  parent  type  before  the  call  takes  place; 
parameters  of  mode  "in  out"  and  "out"  are  converted  to  the  derived  type  after 
the  call  takes  place.  If  the  result  of  a  derived  function  is  of  the  parent  type 
then  the  result  is  converted  to  the  derived  type. 
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The  conversion  of  parameters  described  above  cannot  be  represented  in  the 
sequence  of  actual  parameter  associations  corresponding  to  the  source  code 
without  interfering  with  source  reconstruction;  however,  these  conversions  could 
be  incorporated  into  the  normalized  actual  parameter  list.  It  was  decided  not 
to  record  these  conversions  because  the  need  for  such  a  conversion  is  easily 
detected  by  comparing  the  base  types  of  the  formal  and  actual  parameters.  Since 
an  implementation  is  already  required  to  compare  the  (sub)types  of  formal  and 
actual  parameters  to  determine  which  constraint  checks  are  needed,  checking  for 
the  need  for  implicit  conversions  should  impose  no  hardship.  Requiring  these 
conversions  to  be  represented  would  force  calls  to  derived  subprograms  to  be 
treated  as  special  cases  when  constructing  a  DIANA  structure.  The  conversion  of 
a  return  value  of  the  parent  type  is  not  represented  for  the  same  reasons. 


4.6.4  PARENTHESIZED  EXPRESSIONS 

Under  some  circumstances  parentheses  have  a  semantic  effect  in  the  Ada 
programming  language.  Consider  the  following  procedure  call: 

P  (  (A)  ); 

The  parentheses  around  the  actual  parameter  “A"  make  it  an  expression  rather 
than  a  variable,  hence  the  corresponding  formal  parameter  must  be  of  mode  "in", 
or  the  program  containing  this  statement  is  in  error.  In  addition,  certain 
parentheses  (such  as  those  contained  in  default  expressions  for  formal 

parameters  of  mode  "in")  must  be  preserved  in  order  to  perform  conformance 
checks.  Hence  DIANA  defines  a  parenthesized  node.  Not  only  does  it  contain  a 
reference  to  the  expression  that  it  encloses,  it  records  the  value  (if  the  value 
is  static)  and  the  subtype  of  that  expression. 

Certain  kinds  of  processing  are  not  affected  by  the  presence  or  absence  of 
parentheses.  To  allow  the  parenthesized  node  to  be  easily  discarded  as  the 
DIANA  is  read  in,  a  restriction  was  added  to  the  semantic  specification  of 
DIANA:  a  semantic  attribute  which  denotes  an  expression  can  never  reference  a 

parenthesized  node;  it  must  designate  the  node  representing  the  actual 

expression  instead.  This  principle  also  applies  to  sequences  which  are  created 
expressly  for  semantic  attributes  and  may  contain  expressions,  such  as  the 

various  normalized  sequences.  As  a  consequence  of  this  restriction,  a 

parenthesized  node  can  be  rprer-onced  ijy  only  one  att'^ibute  --  a  structural  one. 
Since  many  of  the  semantic  attributes  were  introduced  as  "shortcuts",  it  would 
be  inappropriate  for  them  to  denote  a  parenthesized  node  anyway. 


4.6.5  ALLOCATORS 

The  subtype  of  an  object  created  by  an  allocator  is  determined  in  one  of 
two  ways,  depending  on  the  class  of  the  object.  The  subtype  of  an  array  or  a 
discriminated  object  is  determined  by  the  qualified  expression,  subtype 
indication,  or  default  discriminant  values.  The  subtype  of  any  other  kind  of 
object  is  "the  subtype  defined  by  the  subtype  indication  of  the  access  type 
definition"  [ARM,  4.8];  i.e.  it  is  the  subtype  determined  by  the  context  (the 
Ada  language  requires  this  type  to  be  determinable  from  the  context  alone). 
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As  a  result  of  these  requirements,  the  sm  exp  type  attribute  of  an 
allocator  creating  an  object  that  Is  not  an  array  or  a  discriminated  object 
denotes  the  type  specification  of  the  context  subtype.  Unfortunately,  the  value 
of  sm  exp  type  is  not  as  easily  determined  in  the  other  case  --  an  appropriate 
subtype  is  not  always  available  for  the  sm  exp  type  attribute  of  an  allocator 
creating  an  array  or  a  discriminated  object. ~  Since  an  allocator  can  create  an 
object  with  a  unique  constraint,  a  collection  that  is  compatible  with  that 
object  may  not  exist.  Consider  the  following  declarations: 

type  AC  is  access  STRING(1..10); 

FIVE  :  POSITIVE  :=  5; 

OBJ  :  AC  :=  new  STRING(1..FIVE) ; 

Although  the  initialization  of  OBJ  will  result  in  a  constraint  error,  the 
declaration  of  OBJ  is  legal,  and  hence  must  be  represented  in  the  DIANA 
structure. 

It  may  seem  that  it  would  be  simple  to  make  an  anonymous  subtype  for  this 
sort  of  allocator,  just  as  anonymous  subtypes  are  created  for  other  kinds  of 
expressions.  But  due  to  the  way  in  which  access  types  are  constrained,  the 
construction  of  an  anonymous  subtype  cannot  always  be  performed  as  it  would  be 
for  other  classes  of  types. 

The  anonymous  subtypes  for  other  expressions  are  constructed  from  the  base 
type  of  the  context  type  and  the  new  constraint.  The  base  type  of  an  array  or 
record  type  cannot  have  a  constraint  already  imposed  upon  it  (constrained  array 
type  definitions  create  anonymous  unconstrained  base  types,  and  the  syntax  of  a 
record  type  definition  does  not  allow  a  constraint);  therefore  the  imposition  of 
a  constraint  on  the  base  type  does  not  cause  an  inconsistency. 

The  base  type  of  an  access  type  is  not  always  unconstrained,  nor  does  the 
Ada  language  define  an  anonymous  unconstrained  base  type  for  a  constrained 
access  type.  Associated  with  an  access  base  type  is  a  collection  containing  the 
objects  which  are  referenced  by  access  values  of  that  type.  If  that  base  type 
is  constrained  (i.e.  the  designated  subtype  is  constrained),  then  all  of  the 
objects  in  its  collection  must  have  the  same  constraints.  It  would  be 
inappropriate  to  introduce  an  anonymous  base  type  having  an  unccnstrained 
designated  subtype. 

Unfortunately,  this  means  that  there  is  no  existing  type  that  would  be  an 
appropriate  base  for  the  anonymous  subtype  of  the  allocator  in  the  previous 
example.  The  objects  which  may  be  referenced  by  OBJ  and  the  object  created  by 
the  evaluation  of  the  allocator  do  not  belong  to  the  same  collection,  therefore 
they  should  not  have  the  same  base  type.  One  solution  would  be  to  create  an 
anonymous  BASE  type  for  the  allocator;  however,  it  cannot  always  be  determined 
statically  whether  or  not  the  object  created  by  an  allocator  belongs  to  the 
collection  of  the  context  type.  For  instance,  if  the  variable  FIVE  had  the 
value  10  rather  than  5,  then  it  would  be  inconsistent  to  construct  an  anonymous 
base  type  for  the  allocator,  since  the  object  it  creates  belongs  to  the 
collection  associated  with  AR. 
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It  was  decided  that  in  the  case  of  an  allocator  creating  an  array  or  a 
discriminated  object  the  sm  exp  type  attribute  would  denote  the  context  subtype, 
just  as  it  does  for  other  kinds  o7~  allocators.  Within  the  context  of  the 
allocator  it  can  easily  be  determined  what  constraint  checks  need  to  be 
performed  by  comparing  the  subtype  of  the  qualified  expression  or  the  subtype 
introduced  by  the  allocator  with  the  designated  subtype  of  the  context  type. 


4.6.6  AGGREGATES  AND  STRING  LITERALS 

The  Ada  programming  language  allows  the  component  associations  of  an 
aggregate  to  be  given  in  two  forms:  named  and  positional.  If  named 
associations  are  used  then  the  associations  do  not  necessarily  appear  in  the 
same  order  as  the  associated  components.  To  simplify  subsequent  processing  of 
the  aggregate,  the  aggregate  node  contains  a  normalized  list  of  component 
associations. 

Since  records  have  a  static  number  of  components  (the  expression  for  a 
discriminant  governing  a  variant  part  must  be  static  in  an  aggregate),  it  is 
possible  for  the  component  associations  to  be  replaced  by  a  sequence  of 
expressions  in  the  order  of  the  components  to  which  they  correspond. 

Unfortunately,  the  associations  of  array  aggregates  are  not  necessarily 
static.  In  addition,  it  is  not  always  desirable  to  replace  a  static  range  by 
the  corresponding  number  of  component  expressions,  particularly  if  the  range  is 
large.  Hence  the  normalized  list  of  component  associations  for  an  array 
aggregate  does  not  necessarily  consist  of  expressions  alone  (obviously  all 
positional  associations  will  remain  as  expressions  in  the  normalized  sequence). 

A  single  component  association  may  contain  several  choices.  Since  the 
component  associations  in  the  normalized  sequence  must  he  in  the  proper  order, 
and  since  the  original  choices  do  not  necessarily  correspond  to  components  whicn 
are  contiguous  (much  less  in  the  proper  order),  each  component  association 
containing  more  than  one  choice  is  decomposed  into  two  or  more  associations. 
The  normalized  sequence  does  not  correspond  to  source  code,  hence  the  only 
requirements  imposed  on  the  decomposition  process  are  that  the  resulting 
associations  be  semantically  equivalent  to  the  original  ones,  and  that  eacn 
association  be  either  the  component  expression  itself  or  a  named  associat'on 
having  a  single  choice. 

An  "others"  choice  does  not  necessarily  denote  consecutive  components, 
therefore  it  is  treated  as  if  it  were  an  association  with  multiple  choices. 
Each  component  or  range  of  components  represented  by  the  "others"  choice  is 
represented  by  a  component  expression  or  a  named  association  in  the  normalized 
sequence. 

If  a  choice  in  an  array  aggregate  is  given  by  a  simple  expression,  and  it 
can  be  determined  statically  that  the  expression  belongs  to  the  corresponding 
index  subtype  then  that  association  may  be  replaced  by  the  component  expression. 

A  subaggregate  is  syntactically  identical  to  an  aggregate,  therefore  it  is 
represented  in  a  DIANA  structure  by  the  same  kind  of  node.  The  only  problem 
arising  from  this  representation  is  caused  by  the  sm  exp  type  attribute.  A 
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subaggregate  is  an  aggregate  corresponding  to  a  sub-dimension  of  a 
multidimensional  array  aggregate.  An  aggregate  corresponding  to  an  array 
component  or  a  record  component  is  NOT  a  subaggregate.  Since  a  subaggregate 
corresponds  to  a  dimension  rather  than  a  component,  it  does  not  have  a  subtype. 
A  subaggregate  does,  however,  have  bounds  (although  the  bounds  may  be  implicit, 
as  specified  in  section  4.3.2  of  the  Ada  Reference  Manual).  In  order  to 
correctly  represent  the  subaggregate,  the  sm  discrete  range  attribute  was 
defined  for  the  aggregate  node;  it  denotes  the  bounds  of  the  subaggregate,  and 
is  void  for  an  aggregate  that  is  not  a  subagqreqate.  The  sm  exp  type  attribute 
of  a  subaggregate  is  void. 

A  string  literal  is  not  syntactically  like  an  aggregate,  therefore  it  is 
represented  by  a  string  literal  node.  However,  a  string  literal  may  be  a 
subaggregate  if  it  occurs  ^in  a  multidimensional  aggregate  at  the  place  of  a 
one-dimensional  array  of  a  character  type"  [ARM,  4.3.2].  To  accomodate  this 
case,  the  string_1iteral  and  aggregate  nodes  were  placed  in  the  class  AGG_EXP, 
and  the  sm  discrete  range  attribute  was  defined  for  both  nodes. 

As  previously  stated,  an  aggregate  may  have  an  anonymous  subtype.  In  most 
cases  the  constraints  for  the  subtype  are  obtained  from  the  aggregate  itself 
with  no  conflict  as  to  which  constraints  to  use.  However,  in  the  case  of  an 
aggregate  which  contains  more  than  one  subaggregate  for  a  particular  dimension 
the  choice  is  not  clear.  To  add  to  the  confusion,  the  bounds  of  the 
subaggregates  for  a  particular  dimension  are  not  necessarily  the  same.  Though 
the  Ada  language  requires  a  check  to  be  made  that  all  of  the  (n-l)-dimensional 
subaggregates  of  an  n-dimensional  multidimensional  array  aggregate  '*  .ve  the  same 
bounds,  a  program  containing  a  violation  of  this  condition  is  not  in  error; 
instead,  a  constraint  error  is  raised  when  the  aggregate  is  evaluated  durino 
execution. 

DIANA  does  not  specify  which  subaggregate  the  constraint  for  a  particular 
dimension  is  taken  from.  If  all  of  the  subaggregates  have  the  same  bounds  tnen 
it  does  not  matter  which  is  chosen.  If  the  bounds  are  not  the  same  then  it 
still  does  not  matter,  since  the  constraint  error  will  be  detected  regardless  of 
which  bounds  are  selected  for  the  anonymous  subtype. 
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4.7  PROGRAM  UNITS 

Numerous  kinds  of  declarations  exist  for  package  and  subprograms  -- 
renaming  declarations,  generic  instantiations,  etc.  The  information  peculiar  to 
each  kind  of  declaration  must  be  accessible  from  the  defining  occurrence  of  that 
entity.  Rather  than  have  a  different  kind  of  defining  occurrence  with  different 
attributes  for  each  kind  of  declaration,  DIANA  has  only  one  for  a  package  and 
one  for  each  kind  of  subprogram.  Each  such  defining  occurrence  has  an 
sm  unit  desc  attribute  which  denotes  a  UNIT_0ESC  node  that  not  only  indicates 
the  form  of  declaration,  but  records  pertinent  information  related  to  the  entity 
as  well.  The  UNIT  DESC  nodes  for  special  kinds  of  package  and  subprogram 
declarations  are  dTscussed  in  detail  in  the  following  sections. 

The  defining  occurrence  of  a  package  or  subprogram  that  is  introduced  by  an 
ordinary  declaration  does  not  denote  a  UNIT_DESC  node  defined  exclusively  for  a 
particular  kind  of  declaration.  Instead,  it~denotes  the  body  of  the  subprogram 
or  package,  if  it  is  in  the  same  compilation  unit.  Although  this  information  is 
not  vital  for  a  defining  occurrence  that  does  not  correspond  to  a  body 
declaration,  this  "shortcut"  may  be  used  for  optimization  purposes. 


4.7.1  RENAMED  UNITS 

The  Ada  programming  language  allows  renaming  declarations  for  packages, 
subprograms,  and  entries.  These  declarations  introduce  new  names  for  the 
original  entities.  In  a  few  special  cases  an  entity  may  even  be  renamed  as 
another  kind  of  entity.  A  package  or  subprogram  renaming  declaration  has  the 
same  DIANA  structure  as  an  ordinary  package  or  subprogram  declaration;  the  fact 
that  it  is  3  renaming  is  indicated  by  the  as  unit  kind  attribute,  which  denotes 
a  renanies_unit  node. 

If  the  entity  is  being  renamed  as  the  same  kind  of  entity  (i.e.  a  package 
is  being  renamed  as  a  package,  a  procedure  as  a  procedure,  etc.)  then  uses  of 
the  new  name  will  have  the  same  syntactic  structure  as  uses  of  the  old  name,  and 
can  appear  in  the  same  kinds  of  context.  For  instance,  a  used  occurrence  of  the 
name  of  a  function  which  is  renamed  as  a  function  will  appear  as  a  function  call 
within  the  context  of  an  expression.  The  function  call  must  be  given  in  prefix 
form,  just  as  a  function  call  containing  the  old  name  must.  A  function  id  can 
represent  the  new  name  without  conveying  any  incorrect  semantic  information,  and 
used  occurrences  of  this  name  can  refer  to  the  function_id  without  introducing 
any  inconsistencies  in  the  DIANA  tree. 
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In  such  cases  the  new  name  is  represented  by  the  same  kind  of  DEF  NAME  node 
as  the  original  entity,  the  sm  unit  kind  attribute  of  which  denotes  a 
renanes_un1t  node.  Because  the  def i ni ng  occurrence  represents  a  new  name  rather 
than  a”new  entity,  the  remainder  of  the  semantic  attributes,  except  for  sm  spec 
for  a  subprogram  name,  have  the  same  values  as  those  of  the  original  entity. 
Since  a  new  formal  part  is  given  in  the  renaming  of  a  subprogram,  the  sm  spec 
attribute  must  denote  the  formal  part  corresponding  to  the  new  name.  Access  to 
the  defining  occurrence  of  the  original  unit  is  provided  through  the  as  name 
attribute  of  the  renaines_un1t  node. 

Entities  which  are  renamed  as  other  kinds  of  entities  present  special 
cases.  Consider  a  function  renamed  as  an  operator.  Although  a  used  occurrence 
of  the  new  name  will  still  appear  as  a  function  call  within  the  context  of  an 
expression,  a  function  call  using  the  new  name  may  be  given  in  either  infix  or 
prefix  form.  If  a  function_id  were  used  to  represent  the  new  name  rather  than 
an  operator_1d  then  the  information  conveyed  by  the  type  of  the  defining 
occurrence  node  wot  Id  not  be  correct.  Though  the  entity  is  the  same  function, 
its  new  name  must  be  viewed  as  the  name  of  an  operator.  The  same  is  true  for  an 
attribute  renamed  as  a  function  --  though  a  used  occurrence  returns  the  value  of 
the  attribute,  it  will  look  like  a  function  call,  not  an  attribute. 

An  entry  renamed  as  a  procedure  presents  a  different  problem.  The  syntax 
for  procedure  calls  and  entry  calls  is  identical;  however,  from  a  semantic 
perspective,  call  statements  using  the  new  name  are  procedure  calls,  not  entry 
calls.  A  call  statement  containing  the  new  name  cannot  be  used  for  the  entry 
call  statement  in  a  conditional  or  timed  entry  call,  nor  can  it  be  the  prefix 
for  a  COUNT  attribute. 

With  the  exception  of  an  enumeration  literal  renamed  as  a  function,  all 
entities  which  are  renamed  as  other  kinds  of  entities  are  represented  by  the 
DEF_NAME  node  which  is  appropriate  for  the  new  name.  Applicable  attributes  in 
the”  defining  occurrence  for  the  new  name  have  the  same  values  as  the 
corresponding  attributes  in  the  original  entity.  For  instance,  the  operator_id 
and  function_id  nodes  have  the  same  attributes,  so  that  all  semantic  attributes 
except  for  sm”unit  kind  and  sm  spec  may  be  copied.  On  the  other  hand,  none  of 
the  semantTc  attributes  in  a  function_id  are  applicable  for  an  Ada  attribute, 
hence  they  should  have  the  appropriate  values;  i.e.  sm_is_inline  is  false, 
sm_address  is  void,  etc. 

The  only  entity  which  can  be  renamed  as  another  kind  of  entity  without 
changing  either  the  syntactic  or  the  semantic  properties  associated  witn  tne  use 
of  the  name  is  an  enumeration  literal  that  is  renamed  as  a  function.  Ar 
enumeration  literal  and  a  parameterless  function  call  have  the  same  appearance, 
and  there  are  no  semantic  restrictions  placed  on  the  use  of  the  new  name.  The 
new  name  can  be  represented  by  an  enumerat1on_1d,  and  used  occurrences  can  be 
denoted  by  used_object_id  nodes  which  reference  that  enumerat1on_id  (rather  than 
a  funct1on_1d)”  as  the  defining  occurrence.  The  values  of  the  semantic 
attributes  of  the  new  enumeration_id  are  copies  of  those  of  the  original 
enumeration  Id. 
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4.7.2  GENERIC  INSTANTIATIONS 

The  Ada  language  defines  a  set  of  rules  for  an  instantiation,  specifying 
which  entity  is  denoted  by  each  kind  of  generic  formal  parameter  within  the 
generic  unit.  For  example,  the  name  of  a  generic  formal  parameter  of  mode  "in 
out"  actually  denotes  the  variable  given  as  the  corresponding  generic  actual 
parameter.  An  obvious  implementation  of  generic  instantiations  would  copy  the 
generic  unit  and  substitute  the  generic  actual  parameters  for  all  uses  of  the 
generic  formal  parameters  in  the  body  of  the  unit;  however,  this  substitution 
cannot  be  done  if  the  body  of  the  generic  unit  is  compiled  separately.  In 
addition,  a  more  sophisticated  implementation  may  try  to  optimize  instantiations 
by  sharing  code  between  several  instantiations.  Therefore  the  body  of  a  generic 
unit  is  not  copied  in  DIANA  in  order  to  avoid  constraining  an  implementation  and 
to  avoid  introducing  an  inconsistency  in  the  event  of  a  separately  compiled 
body. 


Generic  formal  parameters  may  appear  in  the  specification  portion  of  the 
generic  unit;  for  instance,  a  formal  parameter  of  a  generic  subprogram  may  be 
declared  to  be  of  a  generic  formal  type.  The  specification  portion  of  the 
instantiated  unit  will  necessarily  be  involved  in  certain  kinds  of  semantic 
processing  whenever  the  instantiated  unit  or  a  part  of  its  specification  is 
referenced.  For  example,  when  that  instantiated  subprogram  is  called  it  is 
necessary  to  know  the  types  of  its  parameters.  Semantic  processing  would  be 
facilitated  if  the  entities  given  in  the  specification  could  be  treated  in  a 
"normal"  fashion;  i.e.  it  is  desirable  that  the  appropriate  semantic 
information  be  obtainable  without  a  search  for  the  generic  actual  parameter 
every  time  semantic  information  is  needed.  Because  there  may  be  numerous 
instantiations  of  a  particular  generic  unit,  it  is  not  possible  to  simply  add  an 
additional  attribute  to  the  defining  occurrences  of  the  generic  formal 
parameters  in  order  to  denote  the  corresponding  actual  parameters. 

DIANA  provides  a  solution  in  two  steps,  the  first  of  which  is  the  addition 
of  a  normalized  list  of  the  generic  parameters,  including  entries  for  all 
default  parameters.  Within  this  sequence  (sm  decl  s  of  the  instantiation  node) 
each  parameter  entry  is  represented  by  a  declarative  node  which  does  not 
correspond  to  source  code.  Each  declarative  node  introduces  a  new  defining 
occurrence  node;  the  name  (lx  symrep)  corresponds  to  the  formal  parameter, 
however,  the  values  of  the  semantic  attributes  are  determined  by  the  actual 
parameter  as  well  as  the  kind  of  declarative  nooe  introducing  the  defining 
occurrence. 

After  the  normalized  declaration  list  has  been  created  the  specification 
part  of  the  generic  unit  is  copied.  Every  reference  to  a  generic  formal 
parameter  in  the  original  generic  specification  is  changed  to  reference  the 
corresponding  newly  created  defining  occurrence.  Since  each  DEF  NAME  node 
contains  the  appropriate  semantic  information,  specifications  of  instantiated 
units  do  not  have  to  be  treated  as  special  cases. 

A  DEF_NAME  node  introduced  by  one  of  these  special  declarative  nodes  is  not 
consioered  to  be  an  additional  defining  occurrence  of  the  generic  formal 
parameter;  should  a  defining  occurrence  that  is  introduced  by  such  a  declarative 
node  have  an  sm  first  attribute,  it  will  reference  itself,  not  the  node  for  the 
formal  parameter. 


DIANA  Reference  Manual  Draft  Revision  4  Page  4-46 

RATIONALE 


Since  this  list  of  declarative  nodes  is  a  normalized  list,  all  of  the 
object  declarations  which  appear  in  it  are  SINGLE  declarations,  even  though  the 
generic  formal  parameter  may  have  been  declared  originally  in  a  multiple  object 
declaration.  The  kind  of  declarative  node  created  for  a  generic  formal 
parameter  is  determined  by  the  kind  of  parameter  as  well  as  by  the  entity 
denoted  by  the  parameter. 

The  name  of  a  formal  object  of  mode  "in"  denotes  "a  constant  whose  value  is 
a  copy  of  the  value  of  the  associated  generic  actual  parameter"  [ARM,  12.3]. 
Thus  a  formal  object  of  mode  "in"  is  represented  by  a  constant  declaration  in 
the  normalized  parameter  list.  The  initial  value  is  either  either  the  actual 
parameter  or  the  default  value,  and  the  subtype  of  the  constant  is  that  of  the 
actual  parameter. 

The  name  of  a  formal  object  of  mode  "in  out"  denotes  "the  variable  named  by 
the  associated  actual  parameter"  [ARM,  12.3].  Hence  a  formal  object  of  mode  "in 
out"  appears  in  the  normalized  parameter  list  as  a  renaming  declaration  in  which 
the  renamed  object  is  the  actual  parameter.  The  values  of  the  attributes  of  the 
new  variab1e_id  are  determined  just  as  they  would  be  for  an  ordinary  renaming. 

The  declarative  nodes  for  both  constant  and  variable  declarations  have  an 
attribute  for  the  type  of  the  object  being  declared.  Unfortunately,  as  type  def 
is  normally  used  to  record  syntax,  but  because  the  declarative  node  does  not 
correspond  to  source  code,  there  is  no  syntax  to  record.  A  possible  solution 
would  be  for  as  type  def  to  reference  the  TYPE_DEF  structure  belonging  to  the 
declaration  o7  the  actual  parameter;  however,  this  structure  is  not  always 
appropriate.  If  the  context  of  the  declaration  of  the  actual  parameter  and  that 
of  the  instantiation  is  not  the  same,  then  an  expanded  name  rather  than  a  simple 
name  might  be  required  in  the  TYPE_DEF  structure  for  the  special  declarative 
node.  Rather  than  force  an  implementation  to  construct  a  new  TYPE_0EF  structure 
in  order  to  adhere  to  the  Ada  visibility  rules,  DIANA  allows  the  value  of 
as  type  def  in  an  OBJECT  DECL  node  generated  by  an  instantiation  to  be 
undefined,  jince  these  declarative  nodes  are  introduced  to  facilitate  semantic 
processing,  not  to  record  syntax,  this  solution  should  not  cause  any  problems. 
Declarative  nodes  for  objects  in  the  copy  of  the  specification  are  treated  in 
the  same  manner. 

The  name  of  a  formal  type  denotes  "the  subtype  named  by  the  associated 
generic  actual  parameter  (the  actual  subtype)"  [ARM,  12.3].  A  gene-ic  forma' 
type  is  represented  in  the  normalized  list  by  a  subtype  declaration.  The  name 
in  the  subtype  indication  corresponds  to  the  generic  actual  parameter,  and  the 
subtype  indication  does  not  have  a  constraint,  hence  the  declaration  effectively 
renames  the  actual  subtype  as  the  formal  type.  The  sm  type  spec  attribute  of 
the  subtype_id  references  the  TYP£_SPEC  node  associated  with  the  actual 
parameter. 

The  name  of  a  formal  subprogram  denotes  "the  subprogram,  enumeration 
literal,  or  entry  named  by  the  associated  generic  actual  parameter  (the  actual 
subprogram)"  [ARM,  12.3].  A  generic  formal  subprogram  appears  in  the  normalized 
list  as  a  renaming  declaration  in  which  the  newly  created  subprogram  renames 
either  the  subprogram  given  in  the  association  list  or  that  chosen  by  the 
analysis  as  the  default.  The  values  of  the  attributes  of  the  new  DEF_NAME  node 
are  determined  just  as  they  would  be  for  an  ordinary  renaming,  "with  the 
exception  of  the  HEADER  node,  which  is  discussed  in  one  of  the  subsequent 
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paragraphs. 

References  to  generic  formal  parameters  are  not  the  only  kind  of  references 
that  are  replaced  in  the  copy  of  the  generic  specification.  Substitutions  must 
also  be  made  for  references  to  the  discriminants  of  a  generic  formal  private 
type,  and  for  references  to  the  formal  parameters  of  a  generic  formal 
subprogram. 

The  name  of  a  discriminant  of  a  generic  formal  type  denotes  "the 
corresponding  discriminant  (there  must  be  one)  of  the  actual  type  associated 
with  the  generic  formal  type"  [ARM,  12.3].  If  a  formal  type  has  discriminants, 
references  to  them  are  changed  to  designate  the  corresponding  discriminants  of 
the  base  type  of  the  newly  created  subtype  (i.e.  the  base  type  of  the  actual 
type).  Since  the  new  subtype  id  references  the  type  specification  of  the  actual 
subtype,  any  direct  manipulation  of  the  subtype_id  will  automatically  access  the 
correct  discriminants. 

The  name  of  a  formal  parameter  of  a  generic  formal  subprogram  denotes  "the 
corresponding  formal  parameter  of  the  actual  subprogram  associated  with  the 
formal  subprogram"  [ARM,  12.3].  If  a  formal  subprogram  has  a  formal  part,  the 
declarative  node  and  defining  occurrence  node  for  the  newly  created  subprogram 
reference  the  HEADER  node  of  the  the  actual  subprogram.  Any  references  to  a 
formal  parameter  are  changed  in  the  copy  of  the  generic  unit  specification  to 
denote  the  corresponding  formal  parameter  of  the  actual  subprogram. 

Consider  the  following  example: 


procedure  EXAMPLE  is 

OBJECT  :  INTEGER  :=  10; 

function  FUNC  (  DUMMY  :  INTEGER  )  return  BOOLEAN  is 
begin 

return  TRUE; 
end  FUNC; 

generic 

F0RMAL_0BJ  ;  INTEGER; 

with  function  FORMAL  FUNC(  X  :  INTEGER  )  return  BOOLEAN; 
package  GEN£R1C_PACK  is 

PACK_OBJECT  :  BOOLEAN  :=  F0RMAL_FUNC  (  X  =>  F0RMAL_0BJ  ); 
end  GENERIC_PACK; 

package  body  GENERIC_PACK  is  separate; 

package  NEW_PACK  is  new  GENERIC_PACK  (  F0RMAL_0BJ  =>  OBJECT, 

FORMAL_FUNC  =>  FUNC  ); 


beg  i  n 
null; 

end  EXAMPLE; 
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If  a  DIANA  structure  were  created  for  package  EXAMPLE,  then  the  normalized 
parameter  list  for  package  NEW_PACK  would  contain  two  declarative  nodes.  The 
first  would  be  a  constant  declaration  for  a  new  F0RMAL_0BJ,  which  would  be 
initialized  with  the  INTEGER  value  10.  The  second  would  be  a  renaming 
declaration  for  a  new  F0RMAL_FUNC;  the  original  entity  would  be  FUNC,  and  the 
header  of  the  new  F0RMAL_FUNC  would  actually  be  that  of  FUNC.  The  specification 
for  package  NEW_PACK  would  be  a  copy  of  that  of  GENERIC_PACK;  however,  the 
references  to  ~F0RMAL_FUNC  and  F0RMAL_0BJ  would  be  changed  to  references  to  the 
newly  declared  entities,  and  the  reference  to  X  would  be  changed  to  a  reference 
to  DUMMY. 


4.7.3  TASKS 

The  definition  of  the  Ada  programming  language  specifies  that  "each  task 
depends  on  at  least  one  master"  [ARM,  9.4].  Two  kinds  of  direct  dependence  are 
described  in  the  following  excerpt  (section  9.4)  from  the  Ada  Reference  Manual: 

(a)  The  task  designated  by  a  task  object  that  is  the  object,  or  a 
subcomponent  of  the  object  created  by  the  evaluation  of  an  allocator 
depends  on  the  master  that  elaborates  the  corresponding  access  type 
definition. 

(b)  The  task  designated  by  any  other  task  object  depends  on  the  master 
whose  execution  creates  the  task  object. 


Because  of  the  dynamic  nature  of  the  second  kind  of  dependency,  DIANA  does 
not  attempt  to  record  any  information  about  the  masters  of  such  task  objects. 
The  first  kind  of  dependency,  however,  requires  some  sort  of  information  about 
the  static  nesting  level  of  the  corresponding  access  type  definition;  hence  the 
sm  master  attribute  was  added  to  the  type  specification  of  access  types.  Its 
vaTue  is  defined  only  for  those  access  types  which  have  designated  types  that 
are  task  types.  This  attribute  provides  access  to  the  construct  that  would  be 
the  master  of  a  task  created  by  the  evaluation  of  an  allocator  returning  a  value 
of  that  particular  access  type. 

A  master  may  be  one  of  the  following: 

(a)  a  task 

(b)  a  currently  executing  block  statement 

(c)  a  currently  executing  subprogram 

(d)  a  library  package 


A  problem  arose  over  the  type  of  sm  master  --  there  is  no  one  class  in 
DIANA  that  includes  all  of  these  constructs.  The  class  ALL_DECL  contains 
declarative  nodes  for  tasks,  subprograms,  and  packages;  therefore  it  seemed 
appropriate  to  add  a  "dummy"  node  representing  a  block  statement  to  this  class. 
The  block  master  node,  which  contains  a  reference  to  the  actual  block  statement. 
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was  added  to  ALL_DECL  at  the  highest  possible  level,  so  that  It  would  not  be 
possible  to  have  block  naster  nodes  appearing  In  declarative  parts,  etc.  Only 
one  attribute  (as  alT  decl)  other  than  stn  master  has  the  class  ALL  DECL  as  its 
type;  restrictions  on  the  value  of  this  attribute  were  added  to  tKe  semantic 
specification. 


4.7.4  USER-DEFINED  OPERATORS 

The  Ada  programming  language  allows  the  user  to  overload  certain  operators 
by  declaring  a  function  with  an  operator  symbol  as  the  designator.  Because 
these  user-declared  operators  have  user-declared  bodies,  etc.,  they  are 
represented  by  a  different  kind  of  node  from  the  predefined  operators.  The 
predefined  operators  are  represented  by  b1tn_operator  id  nodes,  which  do  not 
have  the  facility  to  record  all  of  the~informatTon  needed  for  user-defined 
operators.  A  user-defined  operator  is  represented  by  an  operator_id  node;  it 
has  the  same  set  of  attributes  as  the  function_1d. 

A  special  case  arises  for  the  inequality  operator.  The  user  is  not  allowed 
to  explicitly  overload  the  inequality  operator;  however,  by  overloading  the 
equality  operator,  the  user  IMPLICITLY  overloads  the  corresponding  inequality 
operator.  The  result  returned  by  the  overloaded  inequality  operator  is  the 
complement  of  that  returned  by  the  overloaded  equality  operator. 

Since  the  declaration  of  the  overloaded  inequality  operator  is  implicit, 
the  declaration  is  not  represented  in  the  DIANA  tree  (to  do  so  would  interfere 
with  source  reconstruction).  At  first  glance  it  may  seem  that  a  simple 
implementation  of  the  implicitly  declared  inequality  operator  would  be  to 
replace  all  uses  of  the  operator  by  a  combinatioh  of  the  "not'  operator  and  the 
equality  operator  (i.e.  "X  /=  Y"  would  be  replaced  by  "not  (  X  =  Y  )"  ).  While 
this  approach  may  be  feasible  for  occurrences  of  the  inequality  operator  within 
expressions,  it  will  not  work  for  occurrences  in  other  contexts.  For  instance, 
this  representation  would  not  be  appropriate  for  a  renaming  of  the  implicitly 
declared  inequality  operator,  or  for  an  implicitly  declared  operator  that  is 
used  as  a  generic  actual  parameter. 

In  order  for  used  occurrences  (used_naroe_1d  nodes)  to  have  a  defining 
occurrence  to  reference,  the  implicHly  declared  inequai'ty  ope’-ator  is 
represented  by  an  operator_id.  Unfortunately,  this  operator  does  not  have  a 
header  or  a  body  to  be  referenced  by  the  attributes  of  the  operator_id;  some 
indication  that  this  operator  is  a  special  case  is  needed.  Thus  the 
Infill cl t_not_eq  node  was  defined.  Instead  of  referencing  a  body,  the 
as  unit  desc~attribute  of  an  operator  id  corresponding  to  an  implicitly  declared 
inequality  operator  denotes  an  1mpTic1t_not_eq  node,  which  provides  access  to 
the  body  of  the  corresponding  equality  operator.  The  as  header  attribute  of  the 
operator_1d  designates  either  the  header  of  the  corresponding  equality  operator, 
or  a  copy  of  it. 
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4.7.5  DERIVED  SUBPROGRAMS 

A  derived  type  definition  introduces  a  derived  subprogram  for  each 
subprogram  that  is  an  operation  of  the  parent  type  (i-e-  each  subprogram  having 
either  a  parameter  or  a  result  of  the  parent  type)  and  is  derivable.  A 
subprogram  that  is  an  operation  of  a  parent  type  is  derivable  if  both  the  parent 
type  and  the  subprogram  itself  are  declared  immediately  within  the  visible  part 
of  the  same  package  (the  subprogram  must  be  explicitly  declared,  and  becomes 
derivable  at  the  end  of  the  visible  part).  If  the  parent  type  is  also  a  derived 
type,  and  it  has  derived  subprograms,  then  those  derived  subprograms  are  also 
derivable. 

The  derived  subprogram  has  the  same  designator  as  the  corresponding 
derivable  subprogram;  however,  it  does  not  have  the  same  parameter  and  result 
type  profile.  It  should  be  noted  that  it  would  be  possible  to  perform  semantic 
checking  without  an  explicit  representation  of  the  derived  subprogram.  All  used 
occurrences  of  the  designator  could  reference  the  defining  occurrence  of  the 
corresponding  derivable  subprogram.  When  processing  a  subprogram  call  with  that 
designator,  the  parameter  and  result  type  profile  of  the  derivable  subprogram 
could  be  checked.  If  the  profile  of  the  derivable  subprogram  was  not 
appropriate,  and  a  derived  type  was  involved,  then  a  check  could  be  made  to  see 
if  the  subprogram  was  derivable  for  that  particular  type  (i.e.  that  a  derived 
subprogram  does  exist). 

Unfortunately,  the  circumstances  under  which  a  derived  subprogram  is 
created  are  complex;  it  would  be  very  difficult  and  inefficient  to  repeatedly 
calculate  whether  or  not  a  derived  subprogram  existed.  Hence  derived 
subprograms  are  explicitly  represented  in  DIANA.  The  appropriate  defining 
occurrence  node  is  created,  and  the  sm  unit  desc  attribute  denotes  a 
derived  subprog  node,  thereby  distinguishing  the  derived  subprogram  from  other 
kinds  oT  subprograms.  Once  the  new  specification  has  been  created,  the  derived 
subprogram  can  be  treated  as  any  other  subprogram  is  treated;  it  is  no  longer  a 
special  case. 

The  specification  of  the  derived  subprogram  is  a  copy  of  that  of  the 
derivable  subprogram,  with  substitutions  made  to  compensate  for  the  type 
changes.  As  outlined  in  section  3.4  of  the  Ada  Reference  Manual,  all  references 
to  the  parent  type  are  changed  to  references  to  the  derived  type,  and  any 
expression  of  the  parent  type  becomes  the  operand  o^  a  type  conve’-sion  that  has 
the  derived  type  as  the  target  type.  The  specification  of  the  derived 
subprogram  deviates  from  the  specification  described  in  the  Aoa  Reference  Manual 
in  one  respect.  The  manual  states  that  "any  subtype  of  the  parent  type  is 
likewise  replaced  by  a  subtype  of  the  derived  type  with  a  similar  constraint" 
[ARM,  3.4].  If  this  suggestion  were  followed,  both  an  anonymous  subtype  and  a 
new  constraint  would  have  to  be  created.  Fortunately,  both  the  requirements  for 
semantic  checking  and  the  semantics  of  calls  to  the  derived  subprogram  allow  a 
representation  which  does  not  require  the  construction  of  new  nodes  (or 
subtypes) . 

All  references  to  subtypes  of  the  parent  type  are  changed  to  references  to 
the  derived  type  in  the  specification  of  the  derived  subprogram.  Because 
semantic  checking  requires  only  the  base  type,  this  representation  provides  all 
of  the  information  needed  to  perform  the  checks.  A  call  to  a  derived  subprogram 
is  equivalent  to  a  call  to  the  corresponding  derivable  subprogram,  with 
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appropriate  conversions  to  the  parent  type  for  actual  parameters  and  return 
values  of  the  derived  type.  Though  the  derived  subprogram  has  its  own 
specification,  it  does  not  have  its  own  body,  thus  the  the  type  conversions 
described  in  section  3.4  of  the  Ada  Reference  Manual  are  necessary.  In  addition 
to  performing  the  required  type  conversions  to  the  parent  type,  an 
implementation  could  easily  perform  conversions  to  subtypes  of  the  parent  type 
when  appropriate,  thereby  eliminating  the  need  to  create  an  anonymous  subtype  of 
the  derived  type.  The  derived_subprog  node  provides  access  to  the  defining 
occurrence  of  the  corresponding  derivable  subprogram  (and  hence  to  the  types  and 
subtypes  of  its  formal  parameters). 

Although  the  defining  occurrence  of  a  derived  subprogram  is  represented  in 
DIANA,  its  declaration  is  not,  even  though  the  Ada  Reference  Manual  states  that 
the  implicit  declaration  of  the  derived  subprogram  follows  the  declarations  of 
the  operations  of  the  derived  type  (which  follow  the  derived  type  declaration 
itself).  Consequently  the  defining  occurrence  of  a  derived  subprogram  can  be 
referenced  by  semantic  attributes  alone. 


Section  4.8 


PRAGMAS 


4.8  PRAGMAS 

The  Ada  progranning  language  allows  pragmas  to  occur  in  numerous  places, 
most  of  which  may  be  in  sequences  (sequences  of  statements,  declarations, 
variants,  etc.).  To  take  advantage  of  this  fact,  several  DIANA  classes  have 
been  expanded  to  allow  pragmas  --  in  particular,  those  classes  which  are  used  as 
sequence  element  types  and  which  denote  syntactic  constructs  marking  places  at 
which  a  pragma  may  appear.  For  instance,  the  class  STM_ELEM  contains  the  node 
stm^pragma  and  the  class  STM.  All  constructs  which  are  defined  as  sequences  of 
statements  in  the  Ada  syntax  are  represented  in  DIANA  by  a  sequence  containing 
nodes  of  type  STM_ELEM. 

The  approach  taken  for  the  representation  of  comments  could  have  been 
applied  to  pragmas;  i.e,  adding  an  attribute  by  which  pragmas  could  be  attached 
to  each  node  denoting  a  construct  that  could  be  adjacent  to  a  pragma.  This 
approach  has  two  disadvantages;  there  is  a  need  to  decide  if  a  pragma  should  be 
associated  with  the  construct  preceding  it  or  the  one  following  it;  and  the 
attribute  is  "wasted"  when  a  pragma  is  not  adjacent  to  the  node  (which  will  be 
the  most  common  case).  Since  the  set  of  classes  needing  expansion  is  a  small 
subset  of  the  DIANA  classes,  it  was  decided  to  allow  the  nodes  representing 
pragmas  to  appear  directly  in  the  associated  sequences,  exactly  as  given  in  the 
source. 

The  pragma  node  could  not  be  added  directly  to  each  class  needing  it 
without  introducing  multiple  membership  for  the  pragma  node.  Since  the  DIANA 
classes  are  arranged  in  a  hierarchy  (if  one  excludes  class  the  node  void)  such  a 
situation  would  be  highly  undesirable.  Instead,  the  pragma  node  is  included  in 
class  USE_PRAGMA,  which  is  contained  in  class  OECL.  and  an  intermediate  node  is 
included  ~in  the  other  classes.  This  intermediate  node  has  an  as  pragma 
attribute  denoting  the  actual  pragma  node.  The  stm  pragma  node  mentlcnec  at  tne 
beginning  of  this  section  is  an  intermediate  node.  ~ 

Sequences  of  . the  following  constructs  may  contain  pragmas: 

(a)  declarations  (decl_s  and  item_s) 

(b)  statements  (stm_s) 

(c)  variants  (variant_s) 

(d)  select  alternatives  (test_c1ause_elem_s) 
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(e)  case  statement  alternatives  (aUernative_s) 

(f)  component  clauses  (co«p_^rep_s) 

(g)  context  clauses  (context_elem_s) 

(h)  use  clauses  (use_pragiia_s) 


Unfortunately  pragmas  do  not  ALWAYS  appear  in  sequences.  In  a  few  cases  It 
was  necessary  to  add  an  as  pragma  s  attribute  to  nodes  representing  portions  of 
source  code  which  can  contain  pragmas.  These  cases  are  discussed  in  the 
following  paragraphs. 

The  co«p_1ist  node  (which  corresponds  to  a  component  list  in  a  record  type 
definition)  has  an  as  pragma  s  attribute  to  represent  the  pragmas  occurring 
between  the  variant  part  and  the  end  of  the  record  type  definition  (i.e. 
between  the  “end  case"  and  the  "end  record"). 

The  labeled  node,  which  represents  a  labeled  statement,  has  an  as  pragma  s 
attribute  to  denote  the  pragmas  appearing  between  the  label  or  labels  and  the 
statement  itself. 

Pragmas  may  occur  before  an  alignment  clause  in  a  record  representation 
clause  (i.e.  between  the  "use  record"  and  the  "at  mod"),  hence  the 
aligmnent^clause  node  also  has  an  as  pragma  s  attribute.  If  a  record 
representation  clause  does  not  have  an  alignment  clause  then  a  pragma  occurring 
after  the  reserved  words  "use  record"  is  represented  by  an  intermediate 
comp_rep_pragma  node  in  the  comp_rep_.  sequence  (in  this  case  the  comp_rep_s 
sequince~wi 1 1  have  to  be  constructed'whether  any  component  clauses  exist  or 
not) . 


Finally,  the  compilation__un1t  node  defines  an  as  pragma  s  attribute  which 
denotes  a  non-empty  sequence^in  one  of  two  cases.  A  compilation  may  consist  of 
pragmas  alone,  in  which  case  the  as  pragma  s  denotes  the  pragmas  given  for  the 
compilation,  and  the  other  attributes  are  empty  sequences  or  void. 

If  the  compilation  contains  a  compilation  um’t  then  as  pragma  s  represents 
the  pragmas  which  follow  the  compilation  unit  and  are  not  associated  with  the 
following  compilation  unit  (if  there  is  a  compilation  unit  following  it  at  ail). 
INLINE  and  INTERFACE  pragmas  occurring  between  compilation  units  must  be 
associated  with  the  preceding  compilation  unit  according  to  the  rules  of  the  Ada 
programming  language.  LIST  and  PAGE  pragmas  may  be  associated  with  either  unit 
unless  they  precede  or  follow  a  pragma  which  forces  an  association  (i.e.  a  LIST 
pragma  preceding  an  INLINE  pragma  must  be  associated  with  the  previous 
compilation  unit,  since  pragmas  in  DIANA  must  appear  in  the  order  given,  and  the 
INLINE  pragma  belongs  with  the  previous  unit).  These  four  pragmas  are  the  only 
ones  which  may  follow  a  compilation  unit. 

Certain  pragmas  may  be  applied  to  specific  entities.  Although  the  presence 
of  these  pragmas  must  be  recorded  as  they  occur  in  the  source  (to  enable  the 
source  to  be  constructed),  it  would  be  convenient  if  the  information  that  they 
conveyed  were  readily  available  during  semantic  processing  of  the  associated 
entity.  Hence  DIANA  defines  additional  attributes  to  record  pertinent  pragr-a 
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information  in  the  nodes  representing  defining  occurrences  of  certain  entities 
to  which  pragmas  may  be  applied.  The  following  pragmas  have  corresponding 
semantic  attributes: 


(a)  CONTROLLED 

sm  is  controlled  in  the  access  node 

(b)  INLINE 

sm  is  inline  in  the  generic_1d  and  SUBPROG_NAME  nodes 

(c)  INTERFACE 

sm  interface  in  the  SUBPROG_NAME  nodes 

(d)  PACK 

sm  is  packed  in  the  UNCONSTRAINED_COMPOSITE  nodes 

(e)  SHARED 

sm  is  shared  in  the  wariabie_1d  node 


Although  it  may  seem  that  the  pragmas  OPTIMIZE,  PRIORITY,  and  SUPPRESS 
should  also  have  associated  attributes,  they  do  not.  Each  of  these  pragmas 
applies  to  the  enclosing  block  or  unit.  The  information  conveyed  by  the 
OPTIMIZE  and  PRIORITY  pragmas  could  easily  be  incorporated  into  the  DIANA  as  it 
is  read  in.  The  SUPPRESS  pragma  is  more  complicated  --  not  only  is  a  particular 
constraint  check  specified,  but  the  name  of  a  particular  entity  may  be  given  as 
well.  SUPPRESS  is  too  dependent  upon  the  constraint  checking  mechanism  of  an 
implementation  to  be  completely  specified  by  DIANA;  in  fact,  the  omission  of  the 
constraint  checks  is  optional. 


CHAPTER  5 


EXAMPLES 
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This  chapter  consists  of  examples  of  DIANA  structures.  Each  example 
contains  a  segment  of  Ada  source  code  and  an  illustration  of  the  resulting  DIANA 
structure.  Each  node  is  represented  by  a  box,  with  its  type  appearing  in  the 
upper  left-hand  corner.  Structural  attributes  are  represented  as  labeled  arcs 
which  connect  the  nodes.  All  other  kinds  of  attributes  appear  inside  the  noce 
itself;  code  and  semantic  attributes  are  represented  by  a  name  and  a  value, 
while  lexical  attributes  representing  names  or  numbers  appear  as  strings  (inside 
of  quotes).  All  sequences  are  depicted  as  having  a  header  node,  even  if  the 
sequence  is  empty.  If  the  copying  of  a  node  is  optional,  it  is  NOT  copied  in 
these  examples. 

These  illustrations  DO  NOT  imply  that  all  DIANA  representations  of  these 
particular  Ada  code  segments  must  consist  of  the  same  combination  of  nodes  ana 
arcs.  For  instance,  an  implementation  is  not  required  to  have  a  heade  node  for 
a  sequence.  The  format  for  these  examples  was  selected  because  it  seemed  to  be 
the  most  straightforward  and  easy  to  understand. 

In  certain  instances  an  arc  may  point  to  a  short  text  sequence  describing 
the  node  that  is  referenced  rather  than  pointing  to  the  node  itself.  This  is 
done  for  any  of  the  following  reasons: 

0  the  node  is  pictured  in  an  example  on  anotner  page 

0  the  node  is  not  oictured  in  any  of  the  examples 

0  the  node  represents  a  predefined  entity  which  cannot  be  depicted 
because  it  is  implementation-dependent 

0  the  node  is  on  the  same  page,  but  pointing  to  it  would  cause  arcs  to 
cross  and  result  in  a  picture  that  would  be  difficult  to  understand 
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CHAPTER  6 

EXTERNAL  REPRESENTATION  OF  DIANA 


The  contents  of  this  chapter  win  be  included  at  a  later  date. 


CHAPTER  7 

THE  DIANA  PACKAGE  IN  ADA 


The  contents 'of  this  chapter  will  be  included  at  a  later  date. 
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PARTITIONS  :  2 

STRICT  CLASSES  :  94 

STRICT  CLASSES  NOT  DEFINING  ATTRIBUTES  :  35 

STRICT  CLASSES  THAT  DO  NOT  SERVE  AS  TYPES  :  55 

STRICT  CLASSES  THAT  DO  NOT  SERVE  AS  TYPES 
AND  DO  NOT  DEFINE  ATTRIBUTES  :  3 

LEAF  NODES  :  207 

LEAF  NODES  NOT  DEFINING  ATTRIBU'^ES  :  92 


ATTRIBUTES  :  135 
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PARTITIONS  (UNINCLUDED  CLASSES) 


ALL  SOURCE 
TYPE  SPEC 


STRICT  CLASSES  THAT  DO  NOT  SERVE  AS  TYPES  AND  DO  NOT  DEFINE  ATTRIBUTES 

FULL_TYPE_SPEC 

GENERIC_PARAM 

SEQUENCES 
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STRICT  CLASSES  THAT  00  NOT  DEFINE  AHRIBUTES 


ALIGNMENT  CLAUSE 
ALL  OECL  ■ 
ALTERNATIVE  ELEM 
BODY 
CHOICE 

COMP  REP  ELEM 
constraint 

CONTEXT  ELEM 
OECL 

DISCRETE  RANGE 
EXP 

FULL_TYPE_SPEC 
GENERAL_ASSOC 
GENERIC  PARAM 
HEADER  ■ 

ITEM 

ITERATION 

MEMBERSHIP_OP 

NAME 

PARAM 

PRE0EF_NAME 
SEQUENCES 
SHORT  CIRCUIT  OP 
SOURCE  NAME 
STM 

STM  ELEM 

TEST  CLAUSE  ELEM 

type'def  • 

TYPE  jPEC 
UNIT  OESC 

unit“kind 

USE_PRAGMA 
USED_NAME 
VARIANTJLEM 
VARIANT  PART 
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STRICT  CLASSES  THAT  DO  NOT  SERVE  AS  TYPES 


AGG  EXP 

all“source 

ARR'ACC  DER_DEF 

block_l5op 

CALL  STM 
CLAUSES  STM 
COMP  NAME 

constrained 

CONSTRAINED  DEF 

DERIVABLEJPEC 

DSCRMT  PARAM_0ECL 

ENTRY_STM 

EXP  OECL 

EXP~EXP 

EXP'VAL 

EXP'VAL  EXP 

FOR~REV~ 

FULL_TYPE_SPEC 

GENERIC_PARAM 

ID_0ECL 

I0_S_0ECL 

INIT  OBJECT_NAME 

LABEL  NAME 

MEMBERSHIP 

NAME  EXP 

NAME'VAL 

NAMED  ASSOC 

NAMED'REP 

NON  GENERIC  OECL 

non'task 

non“task_name 

0BJECT_0ECL 

object_name 

PARAM  NAME 
private  SPEC 
QUAL  CONV 

real" 

REAL_CONSTRAINT 
RENAME  INSTANT 
SEQUENCES 

SIMPLE_RENAME  OECL 
STM_WITH_EXP  ~ 
STM_WITH_EXP  NAME 
STM_WITH_NAME 
SUSP  ENTRY_HEAOER 
SUBPROG  NAME 
SUBPROG'PACK_NAME 
TEST_CLAUSE 
TYPE  NAME 


UNCONSTRAINED 

UNCONSTRAINED  COMPOSITE 

UNIT_DECL 

UNIT  NAME 

USED'OBJECT 

VC  NAME 
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LEAF  NODES  (CLASSES  WITHOUT  MEMBERS) 


abort 

accept 

access 

access_def 

address 

aggregate 

alignment 

all 

alternative 

al ternat i ve_pragma 

alternative's 

and_then 

argument_id 

argument_id_s 

array 

assign 

assoc 

attribute 

attribute_id 

block 

block_body 

block_loop_id 

block'mastir 

bltn_operator_id 

box_default 

casi 

character_id 

choice_exp 

choice'others 

choice^range 

choice_s 

code 

comp_l ist 

comp_rep 

comp_reD_Draqma 

como_rep_s 

compi 1  at  ion 

compi lation_uni t 

compi tn_unit_s 

component_id 

cond_clause 

cond_entry 

constant_decl 

constant_id 

constrai ned_access 

constrained_array 

constrai ned_array_def 

constrai ned_record 

context_e1em_s 

context_pragia 

conversion 


dec1_s 

defefred_constant_dec1 

delay 

derived_def 

derived_subprog 

discrete_range_s 

discrete'subtype 

discriminant_id 

dscrint_constraint 

dscrn)t_decl 

dscrmt~decl_s 

entry 

entry_cal 1 

entry_id 

enum_Titeral_s 

enumeration 

enumeration_def 

enumeration_id 

exception_decl 

exception_id 

exit 

exp_s 

f  ixid 

f ixed_constraint 
f ixed'def 
float” 

f loat_constraint 

f loat'def 

for 

formal_dscrt_def 

formal_fixed_def 

formal_f loat_def 

formal_integer_def 

function_cal 1 

function_id 

function_spec 

general_assoc_s 

generic_decl 

generic_id 

goto 

if 

impl icit_not_eq 
in 

inid 

in_op 

in”out 

in_out_id 

Incomplete 

index 

index_constraint 
index  s 
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indexed 

renames_unit 

instantiation 

return 

integer 

reverse 

integer_def 

scalar_s 

iteffl_s 

select_alt_pragma 

iteration_id 

se1ect_alternative 

l_private~ 

selected 

l~private_def 

selecti ve_wait 

l^private^ype.id 

short_circuit 

labe1_id 

s 1 i ce~ 

labeled 

source_name_s 

length_enum_rep 

stm_pragma 

loop 

stm_s 

name_de fault 

strTng_l iteral 

nanie_s 

stub 

named 

subprog_entry_dec 1 

no_de fault 

subprogram_body 

not_in 

subtype_alTocator 

nul l_access 

subtype_decl 

nul l_comp_decl 

subtype_id 

null  stm 

subtype_i nd i cat i on 

numDer_decl 

subunit 

number'id 

task_body 

numeric_l iteral 

task_body_id 

operator__id 

task_decl~ 

or_else 

task'spec 

out 

terminate 

out_id 

test_clause_elem_s 

package_body 

timed_entry~ 

package_decl 

type_decl 

package^id 

type'id 

package”spec 

type'membershiD 

param_s 

unconstrained_array_def 

parenthesized 

universal_f ixed 

pragma 

universal  integer 

pragma_id 

uni versal_real 

pragma_s 

use 

pri vati 

use_oragma_s 

pri vate_def 

used_char 

pri vdte_cype_’d 

useo_name_id 

procedure_cai 1 

used_ob ject_id 

procedure_id 

used_op 

procedure_spec 

variable_decl 

qualified 

variable”id 

qual  if  ied_anocator 

variant 

raise 

variant_part 

range 

variant_pragma 

range_attribute 

variant_s 

range~member sh i p 

void 

record 

while 

record_def 

with 

record_rep 

renames_exc_decl 

renames_obj~decl 
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access_def 

address 

all 

and_then 

argument_id 

assign 

attribute_id 

block_1oop_id 

box_default 

character_id 

choice_others 

code 

component_id 

cond_clause 

cond_entry 

constant_decl 

conversion 

deUy 

oer i ved_aef 
oscrmt_decl 
entry_ca1 1 
enuniefation_id 
exception_dici 
f ixed_constraint 
f ixed^def 
float” 

f 1oat_constraint 

f loat”def 

for 

forma 1_dscrt_def 

formdl_f ixed_def 

formal_float_def 

formal_integer_def 

function_id 

aoto 

if 

i  n_i  d 

in_op 

in'out 

in~out_id 

integer 

integer_de^ 

iteration_id 

1_pri vate 

l”private_def 

l”pri vate_type_id 

labe1_id 

length_enum_rep 

no_default 

not_in 

null  access 


null_comp_decl 

nul 1_stm 

number_dec1 

number_id 

operator_id 

or_else 

out 

out_id 

package_body 

package_decl 

pdckage_id 

parenthesized 

private 

private_def 

pri vate_type_id 

procedure_ca‘l  1 

procedure_id 

procedure_spec 

quai if ied 

raise 

renames_exc_dec 1 
renames_uni t 
return 
reverse 

se1ect_aUernative 

se1ectTve_wait 

stub 

subprog_entry_dec 1 

subtype”id 

task_Dody 

terminate 

timed_entry 

uni versa1_f ixed 

universai_integer 

universal_’'eal 

Lx^ed  char 

used_name_id 

usea_object_id 

used'op 

variible_decl 

void 
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PREDEFINED  AND  USER-DEFINED  TYPES 

source_position  IS  THE  DECLARED  TYPE  OF: 

ALL_SOURCE . 1 x_srcpos 

comments  IS  THE  DECLARED  TYPE  OF: 

ALL_SOURCE. 1x_comments 

symbol_rep  IS  THE  DECLARED  TYPE  OF: 

DE  F_NAME . 1 x_symrep 
DESIGNATOR. lx_symrep 
string_l iteral . 1x_symrep 

value  IS  THE  DECLARED  TYPE  OF: 
f  ixed.cd_1mp1_sman 
REAL.sm_accuracy 
EXP_VAi.sm_va1ue 
NAME_VAL . sm_value 
USED_OBJECT.sm_value 

operator  IS  THE  DECLARED  TYPE  OF: 

D 1 tn_oDerator_ia . sm_ooerator 

number_rep  IS  THE  DECLARED  TYPE  OF: 
numeric  I iteral . 1x_numrep 
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Boolean  IS  THE  DECLARED  TYPE  OF: 
in. 1x_default 
function_cal 1 . lx_pref  ix 
C-iiSTRA  I  NED .  sin_depends_on_dscrint 
OER I VABLE_SPEC . sm_i s_anonymous 
access. sm_is_control led 
generic_id.sm_is_in1 ine 
SUBPROG_NAME.sm_is_inl ine 
UNC0NSTRAINE0_C0MP0SITE.sm_1sJiinited 
UNCONSTRA  INED_C0MP0S  I  T£ .  sm_i  s_pactced 
variable_id.sni_is_s  hared 
yC_NAM£.  sm_rendfr!es_od  j 

Integer  IS  THE  DECLARED  TYPE  OF: 

SCALAR. cd_impl_si2e 
ENUM_LlTERAL.sm_pos 
ENUV  literal. s:ti  rep 


DIANA  Reference  Manual  Draft  Revision  4 
DIANA  CROSS-REFERENCE  GUIDE 


Page  A- 11 


AHRIBUTES 


as_alignment_clause  :  ALIGNMENT_CLAUSE 
«=  record_rep 

as_all_clec1  :  ALL_^DECL 

<*  cotnpi  lation_unit 

as_alternative_s  :  aUernative_s 

<=  bIock_5ody 
<=  case 

as_bloclc_body  :  blocic_body 

<=  block 

as_body  :  BODY 

<=  SUBUNIT_BOCy 

ds_choice_s  :  choice_s 

<=  alternative 
<=  named 
<=  variant 

as_comp_list  :  comq_list 

<=”record_def 
<=  variant 

as_comD_'-3p_s 

<=”recora_rep 

as_comDi tn_uni t_s 
<=  compilation 

as_COnstraint  :  CONSTRAINT 

<=  constrained_array_def 
<=  CONSTRAINED_OEF 

as_context_e !em_s  :  context_e iem_s 

comp i  iac iGn_ijm t 

as_decl_s  :  decl_s 

<=  comp_list 
<=  task_decl 

as_decl_sl  :  decl_s 

<=  package_spec 

asdecls?  :  decls 

<=  package_spec 


:  comp_''2p_s 
:  ccmpltn  unit  S 


as_designator 
<=  selected 


:  DESIGNATOR 
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as  discrete_range  :  DISCRETE_RANGE 

<=  choTce_range 
<=  entry 
<=  F0R_REV 
<=  slice 

as_cliscrete_range_s  :  discrete_range_s 

<=  index_constraint 

as_dscrmt_decl_s  :  dscrtnt_decl_s 

<=  type_dicl 

as_enum_literal_s  :  enum_literal_s 

<=~enumerat i on_def 

as_exp  :  EXP 

<=  alignment 
<=  attribute 
<=  choice_exp 
<=  comp_rep 
<=  DSCRMT_PARAM  OECL 
<=  £XP_0ECL 
<=  EXP  VAL  EXP 
<=  NAMED  ASSOC 
<=  NAMED  jEP 
<=  range~attribute 
<=  REAL  CONSTRAINT 
<=  STM_WITH  EXP 
<=  TEST_  .aUSE 

<=  whi li 

as_e.<pl  :  EXP 

<=  range 

<=  short_circuit 

as_exp2  :  EXP 

.  <=  range 

«=  short_circuit 

as_exp_s  :  exp_s 

<=  indexed 

as_general_assoc_s  :  general_assoc_s 

<=  aggregate 
<=  CALLJTM 
<=  dscrmt_constraint 
<=  function_can 
<=  instantiation 
<=  pragma 

as_header  :  HEADER 

<=  subprogram_body 
<=  UNIT  DECL 
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as_index_s  :  in<jex_s 

<=  unconstrainecl_array_def 

as_item_s  :  item_s 

<=~block_body 
<=  generTc_decl 

as  iteration  :  ITERATION 

<»  loop 

as  list  :  Seq  Of  GENERAL_ASSOC 

<*  general _assoc_s 

as_list  :  Seq  Of  SOURCE JA»E 

<»  source_name_s 

as_list  :  Seq  Of  ENUM_LITERAL 

<=  enum_litera1_s 

asjist  :  Seq  Of  DISCRETEJANGE 

<=  discrete_rdnge_s 

as  list  :  Seq  Of  SCALAR 

<=  scalar_s 

as  list  ;  Seq  Of  index 

<=  index_s 

as  list  :  Seq  Of  dscrmt_decl 

<=  dscrmt_decl_s 

asjist  :  Seq  Of  VARIANTJLEM 

<=  variant_s 

asjist  :  Seq  Of  CHOICE 

<=  choice_s 

as_list  '  Seq  Of  ITEM 

<=  item  s 


as_l ist 

<=  exp_s 

as  list 

<=  stm_s 

as_list 

<=  alternati ve_s 

as_list 

<=  parani_s 

as  list 

<=  deci  s 


:  Seq  Of  EXP 
:  Seq  Of  STMJLEM 
;  Seq  Of  ALTERNATIVEJLEM 
:  Seq  Of  PARAM 


:  Seq  Of  DECL 
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I 


as_list  :  Seq  Of  TEST_CLAUSE_ELEM 

<=  test  clause  eletn  s 


as_list 

<=  name_s 

as_list 

<=  conipUn_unit_s 

as_list 

<=  pragma_s 

as_list 

<=  context_elem_s 
as_list 

<=  use_pragfna_s 

as_l ist 

<=  comp_reD_s 

as_l ist 

<=  argument_id_s 

as  membership  op 
■  <=  MEMBERSHIP 


:  Seq  Of  NAME 
:  Seq  Of  compi lation_unit 
:  Seq  Of  pragma 
:  Seq  Of  CONTEXTJLEM 
:  Seq  Of  USE_PRAGMA 
:  Seq  Of  COMP_REP_ELEM 
:  Seq  Of  argument_id 
:  MEMBERSHIP  OP 


as_name 

<= 


<= 


<= 


<= 


<= 

<= 

<= 

<= 

<= 


<= 


<= 


:  NAME 

accept 

comp_rep 

deferred  constdnt_decl 
DSCRMT_PARAM_DECL 
function_spec 
i  ndex 

name_default 

NAME  EXP 

Q'JAL^CONV 

range_attribute 

RENAME_INSTANr 

REP 

SIMPLE  RENAME_OECL 
stm_wiTh_exp_name 

STM_WITH_NAME 

subtype_Tndication 

subunit 

t>pe_menibe’'ship 

variant_part 


as_name_s  :  name_s 

<=~abort 
<=  use 
<=  with 
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as_param_s  :  param_s 

<*  iccept 

<*  SUSP  ENTRY  HEADER 


as_pragma  :  pragma 

<=  alternative_pragma 
<=  comp_rep_pragma 
<=  contixt_pragma 
<*  select_a1t_pragma 
<=  stm_pragma~ 

<=  variant_pragma 

as_pragma_s  :  pragma_s 

<=  aTignment  ~ 

<=  comp_list 
<=  compTlation_unit 
<=  labeled 


as_qualified  :  qualified 

<=  qualified_anocator 

as_range  :  RANGE 

<=  comp_rep 
<=  range_membership 
<=  REAL_CONSTRAINT 

as_short_c1rcuit_op  :  SHORT_CIRCUIT_OP 

<s  short_cifcuit 

as  source  name  :  SOURCE  NAME • 

<=  BLOCK  LOOP 
<=  F0R_REV 
<*  ID_DECL 
<=  SUBUNIT  BODY 


as_source  name  s  :  source  name_s 

<=  DSCRMT~PARAM_DECL 
<=  rD_S_0ECL 
<=  labeled 

as_stm  :  STM 

<*  labeled 


as_stm_s  :  stro  s 

<=  accept 
<=  alternative 
<=  block_body 
<=  CLAUSES_STM 
<=  loop 

<=  TEST_CLAUSE 

as_stm_sl 

<=  ENTRY  STM 


stm  s 
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as  stin_s2  :  stm  s 

~  <=  £NTRY_STM 

as  subtype  indication  :  subtype  Indication 

~  <=  arr_acc_der_def 
<=  discreti_subtype 
<=  subtype_anocatQr 
<=  subtype'decl 

as_subunit_body  :  SUBUNIT_BODY 

<=  subunit 

as  test  clause_e1em  s  :  test_c1ause_e1em  s 
~  <=~CLAUSES_STM' 

as  type_def  :  TYPE  DEF 

~  <=  OBJECT_DECL 
<=  type_decl 

as_type_inark_name  :  NAME 

<=  renafnes_obj_deci 

as  unit  kind  :  UN[T_KIN0 

■  <=*NON_GENERIC_DECL 

as  use  pragma_s  :  use_pragiiia_s 

<=  with 

as  used  name  :  USED_NAME 

<=~assoG 

as  used  name  id  :  used_name_id 

<=~attrTbute 
<=  pragma 

<=  range_attribute 

as_vari ant_part  :  VARIANT_PART 

<=  como_1ist 

as_variant_s  :  variant_5 

<=  variant_part 

cd  imp!  size  :  Integer 

<=~SCALAR 

cd_impl  small  :  value 

<=~f ixed 

1x_comments  :  comments 

<=  ALL  SOURCE 


1x_defau1t 
<=  in 


:  Boolean 
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lx_nutnrep  :  number_rep 

<a  numeric_l Iteral 

1x_prefix  :  Boolean 

<=  function_can 

lx  srcpos  :  source  position 

<=  ALLJOURCE 

lx  symrep  :  symbol _rep 

<=  DEF  NAME 

<=  desTgnator 
<=  string_l iteral 

sm  accuracy  ;  value 

<=  REAL 

sni_address  :  EXP 

<=  entry  id 
<=  SUBPROG_PACK_NAME 
<=  task_spec 
<=  VC_NAME 

sm_argument_id_s  :  argument_id_s 

<=  pragma_id 

sm  base  type  :  TYPE  SPEC 

<=~non_task 

snt_body  :  BODY 

<=  generic_id 
<=  tasi<_body_id 
<=  task_spec~ 

sm_comp_list  :  comp_1ist 

<=  record 

sm  comD_reD  :  COMP_REP_ELEM 

<=  C0MP_NAME 

sm_comp_typ^  :  TYPE_SPEC 

<=  array 

sm_decl_s  :  decl_s 

~  <=~instant1ation 
<=  task_spec 

sro  defn  :  DEF  NAME 

<=  DESIGNATOR 

sm  depends  on  dscrmt  :  Boolean 
<=  CONSTRAINED 


sm  derivable 


:  SOURCE  NAME 
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<=  deri ved_subprog 

sm  derived 

~  <=  DERIVABLEJPEC 

:  TYPE_SPEC 

sm_desig_type  :  TYPE_SPEC 

<=  access 

<=  constrained_access 
<=  subtype_al locator 

sm  discrete  range 
<=  AGG'EXP 

:  OISCRETE_RANGE 

sm_discriminant_s 
<=  incomplete 
<=  PRIVATE_SPEC 
<=  record 

:  dscrmt_decl_s 

sm_equal 

<=  impl icit_not_eq 

:  SOURCE_NAME 

stn  exp  type 

<=  EXP  EXP 
<=  NAME  EXP 
<=  USED_08JECT 

:  TYPEJPEC 

sm_f irst 

<=  constant_id 
<=  discriminant  id 
<=  PARAM_NAME 
<=  type  Td 
<=  UNITJAME 

:  DEF_NAME 

sm_generic_param_s 
<=  generic_id 

:  item_5 

sni_index_s 
<=  array 

:  index_s 

sm  index  subtype_s  :  scalar_s 

<=  constrained_array 

sm  init  exp  :  EXP 

<=~INIT_OBJECT_NAME 

sm  interface 

<=  SU8PR0G_NAME 

:  PREDEF_NAME 

sm  is  anonymous 

<=  OERIVABLE_SP£C 

:  Boolean 

sm_is_control led 
<=  access 

:  Boolean 
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sm_is_in1ine  :  Boolean 

<=  generic  id 
<=  SUBPROG'NAME 

sm  is  limited  :  Boolean 

~  <=  UNC0NSTRAINE0_C0MP0SITE 

sm  is_packed  :  Boolean 

"  <=  UNCONSTRAINED_COMPOSITE 

sm_is_shared  :  Boolean 

<*  variable_id 

sm_literal_s  :  enum_literal_s 

<=  enumeration 

sm_master  :  ALL_0ECL 

<=  access 

smnormal ized_comp_s  :  general_assoc_s 

<=  aggregate 

sm_norma1  i2ed_dscrmt_s  :  exp_s  -.^ 

<=  constrained_record  'x 

sm  normalized  param  s  :  exp  s 

<=  callJtm 
<=  function_can 

sm  obj  type  :  TYPE  SPEC 

"  <=  OBJECT  NAME 


sm_operator  :  operator 

<=  bltn_operator_id 


sm  pos 

<=  ENUM_LIT£RAL 

• 

Integer 

sm  range 

<=  SCALAR 

1 

RANGE 

sm_renames_exc 

<=  exception_id 

1 

NAME 

sm  renames  obj 

<=  vc'name 

Boolean 

sm  rep 

<=  enum_literal 

• 

Integer 

sm_representation 
<=  record 

REP 

sm  size 

: 

EXP 

OIAMA  Reference  Manual  Draft  Revision  4 
DIANA  CROSS-REFERENCE  GUIDE 


Page  A-20 


<*  task_spec 
UNCONSTRAINED 


sm_spec 

<=  entry  id 
<=  NON  TASK  NAME 


sm  stm 

<=  block_master 
<*  exit 
<=  LABEL_NAME 

sm  storage_size 
<=  access 
<=  task_spec 

sm  type_spec 
<=~index 
<=  PRIVATEJPEC 
<=  RANGE 

<=  REAL_C0NSTRAINT 
<=  task  body  id 
<=  TYPE~NAM£~ 


sm  unit  desc  : 

~  <=~SUBPROG_PACK_NAME 

sm  value'  ’ 

'  <=  EXP  VAL 
<=  NAME  VAL 
<=  USED'OBJECT 


HEADER 

STM 

EXP 

TYPEJPEC 

UNIT_DESC 

value 
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NODES  AND  CLASSES 

**  abort 

IS  INCLUDED  IN: 

STM 

STM  ELEM 
ALL~SOURCE 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  naine_s 

(INHERITED’FROM  ALLJOURCE): 
lx_srcpos 
lx_comnients 

**  accept 

IS  INCLUDED  IN: 

STM 

STM  ELEM 

all'source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 
as~stm_s 
as  param_s 

(INHERITED“FROM  ALLJOURCE): 
lx_srcpQS 
Ix'comments 

**  access 

IS  INCLUDED  IN: 

UNCONSTRAINED 
NON  TASK 
FULL  TYPE  SPEC 
OERIVABLEjPEC 
TYPEJPEC 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_storage_size  :  EXP 

sm'master  :  ALL_DECL 

sin~(jesig_type  :  TYPE_SPEC 

sm~is  controlled  :  Boolean 

(INHERITEO'FROM  UNCONSTRAINED): 

sm_size  :  EXP 

(INHERITED  FROM  NON_TASK): 

stn  base  type  :  TYPE  SPEC 

(INHERITED~FROM~OERIVABLE_SPEC): 

sni_derived  :  TYPE_SPEC 

sin~i s_anonynrous  :  Boolean 

**  access  def 


:  NAME 
:  stm_s 
:  param_s 

:  source_posit1on 
:  comments 


:  name_s 

:  source_position 
:  comments 
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IS  INCLUDED  IN: 

ARR  ACC  DER  DEF 
TYPf  DEF 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ARfi_ACC_DER_DEF) : 

as  subtype_Tndication  : 

(INHERITED'FROM  ALLJOURCE): 

lx_srcpos  ”  : 

Ix'comments  : 


**  address 

IS  INCLUDED  IN: 

NAMEOJEP 

REP 

OECL 

ITEM 

ALL  DECL 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  NAMEDJEP): 
as  exp 

(INHERITED’FROM  REP): 
as  name 

(INHERITED’FROM  ALLJOURCE): 
1x_srcpos 
Ix’cotmients 


**  AGG_£XP 

CLASS  MEMBERS: 

aggregate 
str i ng_l i teral 
IS  INCLUDED  IN: 

EXPJXP 

EXP 

GENERAL  JSSOC 
ALL_SOURC£ 

NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

sm_discrete  range 
(INHERITED  FROM  EXP'EXP); 
sm_exp  type 

(INHERITED  FROM  ALLJOURCE): 
1x_srcpos 
lx  comments 


**  aggregate 

IS  INCLUDED  IN: 

AGG  EXP 
EXP'EXP 
EXP" 


subtype_indication 

source_position 

comments 


EXP 

NAME 

soLirce_position 

comments 


:  DISCRETE_RANGE 

:  TYPEJPEC 

:  source_position 
:  comments 
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GENERAL  ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_genera1_assoc_s 
sm'normal i2ed_comp_s 
(INHERITED  FROM  AGGJXP): 

sni_discrete_range 
(INHERITED  FROM  EXP_EXP): 
sm_exp_type 

(INHERITED  FROM  ALL_SOURCE): 
1x_srcpos 
Ix'cotnments 


**  alignment 

IS  INCLUDED  IN: 

ALIGNMENT_CLAUSE 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_pragma_3 

as_exp 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


**  ALIGNMENTJLAUSE 

CLASS  MEMBERS: 

al ignment 
void 

IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 
IS  THE  DECLARED  TYPE  OF: 

'"scora_>'eo.as_al  ignmenc_ 

**  all 

IS  INCLUDED  IN: 

NAMEJXP 

NAME 

EXP 

GENERAL  ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  NAMEJXP): 
as_name 
sm_exp_type 

(INHERITED  FROM  ALLJOURCE): 


:  genera1_assoc_s 
:  general jssoc_s 

:  DISCRETEJANGE 

:  TYPEJPEC 

:  source_position 
:  comments 


:  3ragma_s 
:  EXP 

:  source_position 
:  comments 


:  source_position 
:  comments 

:  ■  ause 


:  NAME 
:  TYPE  SPEC 
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lx_srcpos 

Ix'coiwnents 


**  ALL_DECL 

CLASS  MEMBERS: 

block_master 

void 

ITEM 

subunit 

DSCRMT_PARAM_OECL 

DECL 

SUBUNIT_BODY 
dscrmt  Heel 
PARAM  ■ 

ID_S  DECL 
ID_0ECL 

nuTl  comp_decl 
REP  ■ 

USE_PRAGMA 

subprogratr_body 

LdSK^DOay 

package^body 

in 

in_out 

out 

EXP_DECL 

deferred_constant_dec1 

exceptiQn_decl 

type  dec!” 

UNIT'DECL 

task'decl 

subtype  deci 

SIMPLE_RENAME  DECL 

NAMED_REP 

record_rep 

use 

oraatT'a 
QBJECT_OECL 
iuniDer_dec  i 
gene'"-:c_decl 

NON_GENERIC_0ECL 
renimes_obj_decl 
renames~exc_decl 
length_inuin_rep 
address 
constant_decl 
variable_dec1 
subprog_int  rydec 1 
package  decl 
IS  INCLUDED  IN:~ 

ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 


:  source_position 
:  comments 
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Ixsrcpos 
Ix^comments 
IS  THE  DECLARED  TYPE  OF: 

compi 1ation_unit.as_a1 l_decl 
access. sm  master 


**  ALL_SOURCE 

CLASS  MEMBERS; 

DEFJAME 

index 

compi 1ation_unit 
compilation 
comp_1 ist 
VARIANT  PART 
ALIGNMENT  CLAUSE 
VARIANT  ELEM 

context“elem 
C0MP_REP  ELEM 
alternatTvejlem 
iteration 
short_circuit  op 

M£MB£RSHIP_0P' 

TEST  CLAUSE  ELEM 

UNIT'OESC 

HEADER 

CHOICE 

CONSTRAINT 

GENERAL  ASSOC 

STM  ELEM 

SEQUENCES 

TyPE_D£F 

ALL  OECL 

SOURCE  NAME 

preoef'name 

variant_part 

void 

al  iaprre'’t 
variant 

var ; dnt_pragmd 
context_pragma 

with 

comp_rep 

comp~rep_pragma 

alternative 

alternative  pragma 

FOR_REV 

whi  le 

andthen 

or_else 

in~op 

not_in 

TEST_CLAUSE 

select  alt_pragma 


source_position 

comments 
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UNITJIND 
derived_subprog 
implicit  not  eq 
BODY 

SUBP_ENTRY_HEADER 

pacicage_spec 

choice_exp 

choice_others 

choice~range 

DISCRETEJANGE 

dscrmt_constraint 

index  constraint 

REAL  CONSTRAINT 

NAMED  ASSOC 

EXP 

STM 

stm_pragma 

altirnati ve_s 

variant_s 

use_pragma_s 

test_clause_elem_s 

stm_s 

source_name_s 
scalar's 
pragma^s 
param_s 
name_s 
i ndex_s 
i tem_s 
exp_s 

enum_l iteral_s 
di screte_range_s 
general_assoc_s 
dscrnit_decl_s 
decl_s 

context_eleni_s 

comp1tn_unit_s 

corrc_rec_s 

choice_s 

argument_id_s 

enurrerat  ion_def 

record_def 

ARR_ACC_0ER  DEF 

CONSTRAINED'OEF 

pri vate_def 

1_pri vate_def 

formal _dscrt_def 

forma l_f1oat_def 

forma l~fixed_def 

formal_integer_def 

block  master 

ITEM  ■ 

subunit 

OBJECT  NAME 
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LABEL  NAME 

UNIT  NAME 

TYPE'NAME 

entry_id 

exception_id 

attribute'id 

bUn_operator_id 

arguiiient_id 

pragtna_id 

for 

reverse 

cond_clause 

select  alternative 

RENAME~INSTANT 

GENERIC_PARAM 

block_body 

stub 

procedure_spec 

function_spec 

entry 

RANGE 

c3iscrece_subtype 

f loat_constraint 

f ixed_constraint 

named” 

assoc 

NAME 

EXPJXP 

labeled 

nun_stm 

abort 

STM  WITH  EXP 

stm~with”name 

accipt 

ENTRY_STM 

BL0CK_L00P 

CLAUSESJTM 

terminate 

constrained_array_def 
aer ived_def 
access_def 

unconstrained_array_def 

subtype_indication 

integer_def 

f ixed_def 

f loat_def 

DSCRMT_PARAM_DECL 

OECL 

SUBUNITBOOY 
INIT  08JECT_NAME 

enum'literal 

iteration_fd 

1abel_id 

block3loop_id 
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NON_TASK_NAME 

tasl(_t)Ody_i(l 

type~id 

subtype_id 

private~type_id 

l_private_type_id 

rinames_unit 

instantiation 

nanie_default 

no_difault 

box_defauU 

range 

range  attribute 
OESIGNATOR 
NAME  EXP 
EXP_VAL 

subtype_an  ocator 

qualifiid  allocator 

AGG_EXP 

return 

delay 

STM_WITH_£XP_NAME 

case 

goto 

raise 

CALL_STM 

cond'entry 

tiined_entry 

loop 

block 

if 

selective_wait 
dscrmt  decl 
PARAM  ' 

ID_S_DECL 

ID_0ECL 

null  comp  decl 
PEP 

use_pragma 

subprogrdm_body 

tasx_body 

package_body 

VCJAME 

number  id 

C0MP_NAME 

PARAM_NAME 

enumeration_id 

character  id 

SUBPROG_PACK_NAME 

generic_id 

USED_OBJECT 

USE0_NAME 

NAME_VAL 

all 
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slice 

indexed 

short_circuit 

nuineric_l  iteral 

EXP_VAL_EXP 

nulT_access 

aggrigate 

string_literal 

assign” 

code 

exit 

entry_cal 1 

procedure_can 

in 

in_out 

out 

EXP_DECL 

deferred_constant_decl 

except ion_decl  ~ 

type  decl 

UNIT'DECL 

task_decl 

subtype_decl 

SIMPLE  RENAME_DECL 

NAMED_REP 

record_rep 

use 

pragma 

variable_id 

constant_id 

component_id 

discriminant_id 

in_id 

out_id 

in_out_id 

SUBPROG_NAME 

packdge_id 

used_char 

used_object_id 

used_op 

used_narne_id 

attribute 

selected 

function  call 

MEMBERSHIP 

QUAL_C0NV 

parenthesized 

OBJECT_DECL 

number~decl 

generic  decl 

NON_GENERIC_DECL 

renames_obj3decl 

renames_exc_decl 

length_inum~rep 
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address 
procedure_id 
operator_Td 
function'id 
range_membership 
type_ietnbership 
conversion 
qualified 
constant_decl 
variabie'deci 
subprog_entry_dec 1 
package~decl 
NODE  ATTRIBUTES? 

(NODE  SPECIFIC): 

1x_srcpos 

1x~comfnents 


**  alternative 

IS  INCLUDED  IN: 

ALTERNATIVE  ELEM 
ALLJOURCE  ~ 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_choice_s 

as~stm_s 

(INHERITED'FROM  ALLJOURCE): 
1x_srcpos 
Ix'comments 

*’*  ALTERNATIVEJLEM 

CLASS  MEMBERS: 

alternative 
a 1 ternat i ve_pragma 
IS  INCLUDED  IN: 

ALLJOURCE 
NODE  ATTRIBUTES: 

(uNHERITED  FROM  ALLJOURCE): 
lx_5rcpos 
lx~cottiments 
IS  THE  DECLARED  TYPE  OF; 

alternati ve_s.as_1 ist  [Seq 

**  alternati V  '_pragma 


IS  INCLUDED  IN: 

ALTERNATIVEJLEM 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_pragina 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 


:  source_position 
:  comments 


:  choice_s 
:  stm_s 

:  source_position 
:  comments 


:  source_position 
:  comments 

Of] 


:  pragma 

:  source_position 
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lx_coraments  :  comments 

**  alternative_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

asjist  :  Seq  Of  ALTERNATIVE  ELEM 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  ^  source_position 

lx  comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

b 1 ock_body . as_a 1 ternat 1 ve_s 
case. is  alternative  s 


**  and_then 

IS  INCLUDED  IN: 

SHORT  CIRCUIT_OP 
ALLJOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SQURCE): 

lx_srcpos  :  source_position 

lx~comments  :  comments 

**  argument_id 

IS  rNCLUOEO  [N: 

PREDEF  NAME 
OEF  NAME 

all'source 

node  ATTRIBUTES: 

(INHERITED  FROM  DEF_NAME): 

lx  symrep  :  symbol  rep 

(INHERITED'FROM  ALL_SOURCE): 

IxsrcpOs  :  sourceposition 

lx  comments  :  comments 

IS  the  declared  type  OF: 

argument_id_s.as_1 ist  [Seq  Of] 

**  argument_id_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL_SOURCE 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC); 
as  list 

(INHERITED“FR0M  ALL_S0URCE): 
lx_srcpos 
lx  comments 

IS  THE  DECLARED  TYPE  OF; 


:  Seq  Of  argument_id 

:  source_position 
:  comments 
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pragma_i  d .  sin_argument_i  d_s 
**  ARR_ACC_DER_DEF 

CLASS  MEMBERS: 

constrai ned_array_def 
derived_def 
access_def 

unconstrained  array  def 

IS  INCLUDED  IN: 

TYPE  DEF 

ALL  Source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  subtype  indication 
(INHERITED’FROM  ALLJOURCE): 

1x_srcpos 
1x~comments 

**  array 

IS  INCLUDED  IN: 

UNCONSTRAINED  COMPOSITE 
UNCONSTRAINED' 

NON  TASK 
FULL  TYPE  SPEC 
DERIVABLE'SPEC 
TYPEJPEC" 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  index_s  :  index_s 

sm'comD  type  :  TYPE  SPEC 

(INHERITED“FROM"UNCONSTRAINEO_COMPOSITE): 

sm  is_iimited  :  Boolean 

sm~is_packed  :  Boolean 

(INHERITED'FROM  UNCONSTRAINED): 

sm_size  :  EXP 

(INHERITED  FROM  NONJASK): 

sm_base  type  :  TYPE_SPEC 

(INHERITED  FR0M"DERIVABL£_SPEC) : 

sm_derived  :  TYPE_SPEC 

sm  is_anonymous  :  Boolean 

**  assign 

IS  INCLUDED  IN: 

STM_WITH_EXP_NAME 
STM_WITH  EXP 
STM 

STMJLEM 

ALLJOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  STM_WITHJXP_NAME ) : 

as  name  :  NAME 


:  subtype_indication 

:  source_position 
:  comments 
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(INHERITED  FROM  STM_WITH  EXP): 
as  exp 

(INHERITED'FROH  ALL_SOURCE): 
1x_srcpos 
1x~cominents 


assoc 

IS  INCLUDED  IN: 

NAME0_ASS0C 
GENERAL_ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_used_name 

(INHERITED  FROM  NAMED^ASSOC) : 
as  exp 

(INHERITED~FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 


attribute 

IS  INCLUDED  IN: 

NAME  VAL 
NAME"EXP 
NAME” 

EXP 

GENERAL  ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_used_name_id 

as”exp 

(INHERITE0”FR0M  NAME_VAL): 
sm  value 

(INHERITED'FROM  NAME_EXP): 
as_nanie 
sm_exD_type 

(INHERITED  FROM  ALl_SOURCE): 
lx_srcpos 

lx  comments 


attribute_id 

IS  INCLUDED  IN: 

PPEOEF_NAME 
DEF  NAME 
ALLjOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  OEF_NAME): 
lx_symrep 

(INHERITED  FROM  ALL_SOURCE): 
lx  srcpos 


:  EXP 

:  source_position 
:  comments 


:  USED_NAME 
:  EXP 

:  source_position 
:  comments 


:  used  name  id 
:  EXP  ■ 

:  value 

:  NAME 
:  TYPE._r^EC 

:  sou'"ce_oositior 

:  comments 


:  symbol _rep 
:  source  position 
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lx  comments 


**  block 

IS  INCLUDED  IN: 

BLOCK  LOOP 
STM 

STM  ELEM 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_b1ock_body 

(INHERITED  FROM  BLOCK_LOOP): 
as_source  name 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 

**  b1ock_body 

IS  INCLUDED  IN: 

BODY 

UNIT  OESC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_item_s 
as3a1ternative_s 
as"stm  s 

(INHERITEO’FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 

b1ock.as_block_body 

**  8L0CK_L00P 

CLASS  MEMBERS: 
loop 
block 

IS  INCLUDED  IN; 

STM 

STM  ELEM 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_source_name 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 

**  block_loop_id 


;  comments 


:  block_body 

:  SOURCE_NAME 

:  source_position 
:  comments 


:  item_s 
:  altefnative_s 
:  stm_s 

:  source_position 
:  comments 


:  SOURCE_NAME 

:  source_position 
:  comments 


IS  INCLUDED  IN: 
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LABEL  NAME 
SOURCE  NAME 
0EF_MAME 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  LABEL_NAME): 
sm  stm 

(INHERITEO'FROM  0EF_NAME): 
lx  symrep 

(INHERITEO'FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 


**  blocl(_master 

IS  INCLUDED  IN: 

ALL  OECL 

all'source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
sm_stm 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 


**  bltn_operator_id 

IS  INCLUDED  IN: 

PR£DEF_NAME 
DEF  NAME 

all'source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  operator 

(INHERITEO'FROM  DEF_NAME): 
1x_symrep 

(INHERITED  FROM  ALLJOURCE): 
lx_srcDOS 
lx  comments 


**  BODY 


CLASS  MEMBERS: 

block_body 

void 

stub 

IS  INCLUDED  IN: 

UNIT  DESC 

allJource 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 
IS  THE  DECLARED  TYPE  OF: 


:  STM 

:  symbol _rep 

:  source_position 
:  comments 


:  STM 

:  source_position 
:  comments 


:  operator 

:  symbol _rep 

:  source_Dosition 
:  comments 


:  source_position 
:  comments 
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generic  id.sm  body 
SUBUNIT"BOOY.ds_body 
task_body_id. sm'body 
task''spec.sni_body 


**  box_default 

IS  INCLUDED  IN: 

GENERIC  PARAM 
UNIT  KIND 
UNIT"DESC 
ALL  SOURCE 
NODE  ATTRIBOTES: 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


**  CALL_STM 

CLASS  MEMBERS: 

entry_cal 1 
procedure_cal 1 
IS  INCLUDED  IN: 

STM_WITH  NAME 
STM 

STM  ELEM 
ALL"SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFICS : 

as_generai_assoc_s 
sm  normalized  pafam_s 

(INHERITED'FROM  STM_WTTH_NAME) : 
as  name 

(INHERITE0"FR0M  ALLJOURCE): 
1x_srcpos 
lx_comments 

*♦  case 

IS  INCLUDED  IN; 

stm_with_exp 

STM 

STMJLEM 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_aUernative  s 

(INHERITED  FROM  STM_WITh_EXP) ; 
as_exp 

(INHERITED  FROM  ALLJOURCE): 
1x_srcpos 
lx  comments 


:  source_position 

:  comments 


:  general_dss0c_s 
:  exp_s 

:  NAME 

:  source_position 
:  comments 


:  alternati ve_s 
;  EXP 

:  source_position 
;  comments 


**  character  id 
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IS  INCLUDED  IN; 

ENUM  LITERAL 
OBJECT  NAME 
SOURCE'NAME 
DEF  NAME 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ENUM_LITERAL) : 
sm_pos 
sm_rep 

(INHERITED  FROM  OBJECT_NAME) : 
sm  obj  type 

(INHERITED'FROM  0EF_NAME): 
lx  symrep 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
1x~cottmients 


**  CHOICE 

CLASS  MEMBERS: 

choice_exp 
choice”others 
choice'range 
IS  INCLUDED  INT 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 
IS  the  DECLARED  TYPE  OF: 

cnoice  s.as  list  [Seq  Of] 


*■*  choice_exp 

IS  INCLUDED  IN; 

CHOICE 
ALL  SOURCE 
node  ATTRIBUTES; 

(NODE  SPECIFIC); 
as  exp 

(INHERITEO'FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 


■**  choice_others 

IS  INCLUDED  IN: 

CHOICE 
ALL_SOURCE 
NODE  ATTRIBUTES; 

(INHERITED  FROM  ALL_SOURCE): 
lx  srcpos 


;  Integer 
:  Integer 

;  TYPE_SPEC 

;  symbol _rep 

:  source_position 
:  comments 


:  source_position 
:  comments 


;  EXP 

;  sour ce_posit ion 
;  comments 


:  source_position 
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lx  comments 


**  choice_range 

IS  INCLUDED  IN: 

CHOICE 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  discrete  range 
(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


**  choice_s 

IS  INCLUDED  IN: 

SEQUENCES 
all  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  list 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 
IS  THE  DECLARED  TYPE  OF: 

alternati ve.as_choice_s 
named. as_choice_s 
variant. as  choice  s 


**  CLAUSES_STM 

CLASS  MEMBERS: 

if 

selective_wait 
IS  INCLUDED  IN: 

STM 

STMJLEM 

ALL_SOURCE 
node  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_test_clause_elein_s 
as  stm_s 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  code 


IS  INCLUDED  IN: 

STM  WITH  EXPJAME 

stm'with'exp 

STM 

STMJLEM 


:  comments 


:  DISCRETEJANGE 

:  source_position 
:  comments 


:  Seo  Of  CHOICE 

:  source_position 
:  comments 


;  test_clause_elem_s 
:  stm_s 

:  source_position 
:  comments 
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ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  STM_WITH_EXP_NAME ) 
as_name  : 

(INHERITED  FROM  STM_WITH_EXP) : 

as  exp  : 

(INHERITED'FROM  ALLJOURCE): 

lx_srcpos  : 

Ix'conwnents  : 


**  comp_list 

IS  INCLUDED  IN: 

ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_decl_s 
as_pragma_s 
as  variant_part 
(INHERITEO'FROM  ALLJOURCE): 
1x_srcpQS 
■ x^comments 
IS  THE  DECLARED  TYPE  OF: 

variant. as_comp_l ist 
record. sm_comp  list 
record_def .as_comp  list 


**  C0MP_NAME 

CLASS  MEMBERS: 

coinponent_id 
di scrimindnt_id 
IS  INCLUDED  IN: 

init_object_name 

0BJECT_NAME 
SOURCE_NAME 
DEF_NAME 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_comp  rep  : 

(INHERITED  FROM~INIT_OBJECT_NAME) : 

sm  init_exp  ~  : 

(INHERITED'FROM  OBJECT_NAME) : 

sm_obj_type  ~  : 

(INHERITED  FROM  0EF_NAME): 

1  x_syiiirep  : 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  : 

lx  comments  : 


*■*  comp_rep 

IS  INCLUDED  IN: 


NAME 

EXP 

source_position 

comments 


decl_s 

pragma_s 

VARIANT_PART 

source_posi tion 
comments 


COMP_RE°_ELEM 

EXP 

TYPEJPEC 

symbol _rep 

sourceposition 

comments 
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COMP  REP  ELEM 
ALL  ?0UR^E 
node  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 
as'range 
as_exp 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx~cofiHnents 

**  COMP_REP_ELEM 

CLASS  MEMBERS: 

comp_rep 
void 

comp  rep_pragma 
IS  INCLUDED  TN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  :  source_posi tion 

1  x_cofnfnents  :  comments 

IS  THE  DECLARED  TYPE  OF: 

comp_rep_s.as_Tist  [Seq  Of] 

COMP'nAME . sm_comp_rep 

**  comp_rep_pragma 


;  pragma 

:  source_position 
:  comments 


**  comp  rep_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_Tist 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
1x_comments 
IS  THE  DECLARED  TYPE  OF: 

record_rep . as_comp_rep_s 


:  Seq  Of  COMP_REP_ELEM 

:  source_position 
:  comments 


IS  INCLUDED  IN: 

COMP  REP  ELEM 
ALL  SOURCE 
NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

as_pragma 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


:  NAME 
:  RANGE 
:  EXP 

:  source_position 
:  comments 


compilation 
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IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_compltn_unit_s 
(INHERITED  FROM  ALLJOURCE): 

1x_srcpos 
lx_comments 

**  compi lation_unit 

IS  INCLUDED  IN: 

ALLJOURCE 
NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

as_context_e1em_s  :  context_elem_s 

as_pragma_i  :  pragmaj 

as_all_decl  :  ALL  OECL 

(INHERITED  FROM  ALLJOURCE): 

1x_srcpos  :  source_position 

1x_cormnents  :  comments 

IS  THE  DECLARED  TYPE  OF: 

compltn_unit_s.as_list  [Seq  Of] 

**  compUn_unit_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC); 

as  list  :  Seq  Of  compilation  unit 

(INHERITED'FROM  ALLJOURCE): 

lx_srcpos  "  :  source_position 

lx_comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

compi lation,as_compitn_unit_s 

**  component_'d 

IS  INCLUDED  IN: 

COMP  NAME 
INIT~OBJECT  NAME 
OBJECTJAME" 

SOURCE  NAME 
DEFJAME 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  COMPJAME): 

sm_comp_rep  :  COMP  REP_ELEM 

(INHERITED  FROM  INITJBJECTJAME) : 

sm_init_exp  :  EXP 

(INHERITED  FROM  OBJECTJAME) : 


:  compUn_unit_s 

:  source_position 
:  comments 
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Slit  obj  type 

(INHERITED'FROM  OEFJAME): 
lx  sytnrep 

(INHERITED'FROM  ALLJOURCE): 
1x_srcpos 
Ix'conments 


**  cond_clause 

IS  INCLUDED  IN: 

TEiT  CLAUSE 
TEST'CLAUSE  ELEM 
ALL  SOURCE  ~ 

NODE  ATTRIBUTES: 

(INHERITED  FROM  TEST_CLAUSE) : 
as_exp 
as'stm  s 

(INHERITED’FROM  ALLJOURCE): 
lx_srcpos 
Ix’comments 

**  cond_entry 

IS  INCLUDED  IN: 

ENTRY  STM 
STM 

STM  ELEM 
ALL'SOURCE 
NODE  .ATTRIBUTES: 

(INHERITED  FROM  ENTRY_StM): 
as_stm_sl 
as~stm”s2 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx ^comments 

**  constantjecl 

IS  INCLUDED  IN: 

OBJECTJECL 
EXPJECL 
ID  S  DECL 
DECL~ 

ITEM 

ALLJECL 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  OBJECTJECL): 
asjypejef 

(INHERITED  FROM  EXPJECL): 
as_exp 

(INHERITED  FROM  IDJJECL): 
as_source  name  s 

(INHERITED  FROM  ALLJOURCE): 


:  TYPEJPEC 

:  symbol _rep 

:  source_position 
:  comments 


:  EXP 
:  stm_s 

:  source_posUion 
:  comments 


:  stm_s 
:  stmj 

:  source_posi tion 
:  comments 


;  TYPEJEF 
:  EXP 

;  source  name  s 
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lx_srcpos 

lx~comments 


**  constant_id 

IS  INCLUDED  IN: 

VC  NAME 

inTt  object  name 

OBJECT  NAME" 

source"name 

0EF_NAME 

ALL  SOURCE 
node  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  first  : 

(INHERITED'FROM  VC_NAME): 

sni_renatnes~obj  : 

stn'address  : 

(INHERITED'FROM  INIT_OBJECT_NAME) 
sm  init_exp  : 

(INHERITED'FROM  OBJECT_NAME) : 

sm_obj  type  : 

(INHERITED  FROM  0EF_NAME): 

lx  symrep  : 

(INHERITED'FROM  ALLJOURCE): 

lx_srcpos  '  : 

Ix'comments  : 


CONSTRAINED 

CLASS  MEMBERS: 

constrained_array 
constrained_access 
constrained_record 
IS  INCLUDED  IN: 

NON_TASK 
FULL_TYPE_SPEC 
OERIVABLEJPEC 
TYPEJPEC 
node  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  depends  on_dscrmt  : 

(INHERITED'FROM  NONJASK): 

sm_base_type  : 

(INHERITED  FROM  OERIVABLEJPEC): 

sm_derived  : 

sm_ i s_anonymous 

**  constra1ned_access 

IS  INCLUDED  IN: 

CONSTRAINED 

NONJASK 

FULL  TYPE  SPEC 


source_posit1on 

comments 


0EF_NAME 

Boolean 

EXP 

*EXP 

TYPEJPEC 

symbol _rep 

source_position 

comments 


Boolean 

TYPEJPEC 

TYPEJPEC 

Boolian 
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DERIVABLE  SPEC 
TYPE  SPEC' 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  desig_type  : 

(INHERITED'FROM  CONSTRAINED): 

sm  depends  on  dscrmt  : 

(INHERITED'FROM  NONJASK): 

sm  base  type  : 

(INHERITED"FR0M~0ERIVABLE_SPEC): 
sm_de rived 

sm'is_anonymous  : 

**  constrained_array 

IS  INCLUDED  IN: 

CONSTRAINED 
NON  TASK 
FULL  TYPE  SPEC 
DERIVABLE'SPEC 
TYPE  SPEC 
node  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  index_subtype  s  : 

(INHERITED'FROM  CONSTRAINED): 

sm  depends  on  dscrmt  : 

(INHERITED'FROM  NONJASK): 

sm  base  type  : 

(INH£RITED'FR0M~DERIVABLE_SPEC): 

sm_derived  : 

sm'i s_anonymous  : 

constrdined_drray_def 

IS  INCLUDED  IN: 

ARR_ACC_DER_DEF 
TYPE  DEF 
ALLJOURCE 
node  ATTRIBUTES: 

(NODE  SPECIFIC); 

as_constraint  : 

(INHERITED  FROM  ARR_ACC_0£R_OEF) : 

as_subtype_indication  : 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ixjomments 

**  CONSTRAINEDJEF 

CLASS  MEMBERS: 

subtype_indicatton 
integer'def 
f  ixed_def 
f loat_def 


TYPEJPEC 

Boolean 

TYPEJPEC 

TYPEJPEC 

Boolean 


sca1ar_s 

Boolean 

TYPEJPEC 

TYPEJPEC 

Boolian 


CONSTRAINT 

subtype_indication 

source_position 

comments 
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IS  INCLUDED  IN: 

TYPE  OEF 

ALL  Source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  constraint 

(INHERITED~FROM  ALLJOURCE): 
lx_srcpos 
Ix'conments 

*♦  constrained_record 

IS  INCLUDED  IN: 

CONSTRAINED 
NON  TASK 
FULL  TYPEJPEC 
DERIVABLE  SPEC 
TYPE  SPEC" 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_norma1 ized  dscrmt_s  :  exp_s 

(INHERITED  FROM  CONSTRAINED): 

sm_depends_on  dscrnit  :  Boolean 

(INHERITED  FROM  NONJASK): 

stn  base  typi  :  TYPE  SPEC 

(INHERITED~FR0M"0ERIVABLE_SPEC): 

stn_derived  ~  :  TYPE_SPEC 

sm~is_anonymoijs  :  Boolian 

**  CONSTRAINT 

CLASS  MEMBERS: 
void 

OISCRETEJANGE 
dscrmt_constraint 
index  constraint 
REAL  CONSTRAINT 
RANGE 

discrete_subtype 
f loat_constraint 
f ixed_ccnstraint 

range" 

range  attribute 
IS  INCLUDED  IN: 

ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  :  source_position 

lx~conmients  :  comments 

IS  THE  DECLARED  TYPE  OF: 

constrai ned_array_def . as  constraint 
CONSTRAINEO_OEF.as_constfaint 


:  constraint 

:  source_position 
:  comments 


CONTEXT  ELEM 
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CLASS  MEMBERS: 

context_pragma 

with 

IS  INCLUDED  IN: 

ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 

context_elem_s.as_list  [Seq 

**  context_e1em_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_list 

(INHERITED  FROM  ALLJOURCE): 
1x_srcpos 
lx_comments 
IS  THE  DECLARED  TYPE  OF: 

compi lation_unit.as_context 

**  context_pragp.2 

IS  INCLUDED  IN: 

CONTEXT  ELEM 
ALL  SOURCE 
NODE  ATTRIBOtES: 

(NODE  SPECIFIC): 

as  pragma 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  conversion 

IS  INCLUDED  IN: 

QUALJONV 
EXP  VALJXP 
EXP'VAL 
EXP'EXP 
EXP~ 

GENERAL  ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  QUALJONV): 
as  name 

(INHERITEO“FROM  EXPJALJXP): 
as_exp 


:  source_position 
:  comments 

Of] 


:  Seq  Of  CONTEXT_ELEM 

:  source_posi t ion 
:  comments 

elem  s 


:  pragma 

:  source_position 
:  comments 


:  NAME 
:  EXP 
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(INHERITED  FROM  EXP_VAL): 

Sin  value 

(INHERITED'FROM  EXPJXP): 
sni_exp  type' 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx_con«nents 

**  DECL 


CLASS  MEMBERS: 

ID  S  DECL 
ID'OECL 

nuTl  comp  decl 
REP  ' 

USE  PRAGMA 
EXP'OECL 

deferred_constant_decl 
except ion_decl 
type  decl” 

UNIT'OECL 

task_decl 

subtype_decl 

SIMPLE_RENAME_DECL 

void 

NAMED_REP 

record_rep 

use 

pragma 

-  08JECT_0£CL 
number^decl 
generic  decl 
N0N_GENERIC_0ECL 
renames_obj_decl 
renames_exc_decl 
1ength_inum_rep 
address 
constant_decl 
variable_decl 
suDprog_entry_dec 1 
package'ded 
IS  INCLUDED  IN:” 

ITEM 

ALL  DECL 
ALL^SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOUP.CE) : 
lx_srcpos 
Ix^comments 
IS  THE  DECLARED  TYPE  OF: 

decl  s.as  list  [Seq  Of] 


**  decl  s 


:  value 

:  TYPE_SPEC 

:  source_position 
:  comments 


:  source_position 
;  comments 
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IS  INCLUDED  IN; 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  list 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
Ix'commerts 
IS  THE  DECLARED  TYPE  OF: 

instantiation.sm_deci_s 
task_spec . sm_dec1 _s 
task'decl.as'decl^s 
package_specTas_dic  1  __s  1 
.as”decl3s2 
cotnp_l  ist.as_decl_s 

**  DEF_NAME 

CLASS  MEMBERS: 

SOURCE_NAME 

PREOEF_NAM£ 

OBJECT_NAME 

LABEL_NAME 

UNIT  NAME 

TYPE  jAME 

void” 

entry_id 

except ion_id 

attplbute_id 

bltn_operator_id 

arguient_id 

pragma  id 

INIT_OBJECT  NAME 

ENUM_LITERAL 

iteration_id 

label_id 

block”looD_id 

NON_TASK_NAME 

task_body_id 

type_id 

subtype_id 

private_type_id 

1  private_type  id 

VC_NAME 

number_id 

COMP_NAME 

PARAM_NAME 

enumefation_id 

character_id 

SUBPROG_PACK_NAME 

generic_id 

variable_id 

constant”id 


:  Seq  Of  OECL 

:  source_position 
:  conments 
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component_id 
discriminant_id 
in_id 
out_id 
in  out  id 
SUBPROG_NAME 
package_id 
procedufe_id 
operator_Td 
function'id 
IS  INCLUDED  IN:  ~ 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

lx  symrep 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
1  x''coniments 
IS  THE  DECLARED  TYPE  OF: 

PARAM  NAME.sni_f irst 
DESIGNATOR. sm_defn 
discriminant_id.sm_f irst 
type_id.sm_fTrst 
constant_id . sm_f irst 
UNIT  NAME.sm  first 


symbo1_rep 

source_position 

comments 


**  deferred  constant  dec! 


IS  INCLUDED  IN: 

ID  S  OECL 

oecl” 

ITEM 

ALL  OECL 
ALLjOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 

(INHERITED  FROM  ID_S_DECL): 

as  sourcenames 
(INHERITED'FROM  ALL_S0URCE); 
1 x_srCDOS 
lx  comments 


source_name_s 

source_position 

comments 


delay 


IS  INCLUDED  IN; 

STM_WITH  EXP 
STM 

STMJLEM 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  STM_WITH_EXP); 
as_exp 

(INHERITED  FROM  ALL  SOURCE): 
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1x_srcpos 

Ix'comments 


**  OERIVABLEJPEC 

CLASS  MEMBERS: 

FULL_TYPE  SPEC 
PRIVATEJPEC 
task  spec 
non_Task 

private 

■'_PT  ivate 

SCALAR 

CONSTRAINED 

UNCONSTRAINED 

enumeration 

REAL 

integer 

constrained_array 
constrained'access 
constrai  ned_recor(j 
UNCONSTRAIN£D_COMPOSITE 
access 
float 
fixed 
array 
record 
IS  INCLUDED  IN: 

TYPE  SPEC 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sni_c:2ri  ved 
sm_is_anonynious 


**  derived_def 

IS  INCLUDED  IN: 

APP_ACC_DER_DFF 
TYPE_0EF 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ARR_ACC_OER_OEF) : 

as  subtype_Tndication  : 

(INHERITEO~FROM  ALL_SOURCE): 

lx_srcpos  : 

Ix'comments  : 


**  derived_subprog 

IS  INCLUDED  IN: 

UNIT  DESC 
ALI  _SOURCE 
NODE  ATTR  iTES: 

(NODE  SPECIFIC): 


source_position 

comments 


TYPEJPEC 

Boolean 


subtype_indication 

source_position 

comments 
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sm  derivable  :  SOURCE  NAME 

(INHERITEO'FROM  ALL_SOURCE): 

lx_srcpos  ~  :  source_position 

lx~conments  :  comments 

**  DESIGNATOR 

CLASS  MEMBERS: 

USED  OBJECT 
USED'NAME 
used~char 
used~object_id 
used~op 
used~name_id 
IS  INCLUDED  TN: 

NAME 
EXP 

GENERAL_ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
sm_defn 
lx  symrep 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 
IS  THE  DECLARED  TYPE  OF: 

selected.as_designator 

**  OISCR£TE_RANGE 

CLASS  MEMBERS: 

RANGE 

discrete_subtype 
range 
void 

range_attribute 
IS  INCLUDED  IN: 

CONSTRAINT 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE); 

lx_srcpos  ~  :  source_position 

lx_comments  :  comments 

IS  the  declared  type  OF: 

entry . as_d i screte_range 

FOR_REV . as_d i sere te_range 

AGG~EXP. sm2discrete_range 

slice.asdTscreterange 

cho i ce_r ange . as_d i sere te_r ange 

discrete_range_3.as_1ist  [Seq  Of] 

*■*  discrete_range_s 


:  DEF_NAME 
:  symbo1_rep 

:  source_position 
:  comments 
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IS  INCLUDED  IN; 

SEQUENCES 
ALL_SOURCE 
NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

as_1ist  ;  Seq  Of  DISCRETE_RANGE 

(INHERITED  FROM  ALLJOURCE): 

1x_srcpos  :  source_posUion 

1x~comments  :  conments 

IS  THE  DECLARED  TYPE  OF: 

index_constraint .as_discrete_range_s 

**  discrete_subtype 

IS  INCLUDED  IN: 

DISCRETE_RANGE 
CONSTRAINT 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_subtype  indication 
(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx_cotmnents 

**  discrifninant_id 

IS  INCLUDED  IN: 

COMP  NAME 
INIT“OBJ£CT_NAME 
OBJECT  NAME 
SOUPCE'nAME 
OEr  NAME 

all"source 

NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

sm_first  ;  DEF_NAME 

(INHERITED  FROM  COMP_NAMEi; 

stn  comp_rep  :  COMP_REP_ELEM 

( INHEorED~-ROM  INIT_GBJECT_NAME) : 

sm  init_exp  :  EXP 

(INHERITED'FROM  OBJECT_NAME) : 

sm  obj_type  ;  TYPE_SPEC 

(INHERITED~FROM  OEF_NAME): 

lx  symrep  ~  :  symbol_rep 

(INHERITED'FROM  ALL_SOURCE): 

1x_srcpos  ~  :  source_position 

Ix'cominents  ;  comments 

**  dscrmt_constraint 

IS  INCLUDED  IN: 

CONSTRAINT 
ALL  SOURCE 


:  subtype_inclication 

:  source_position 
:  comments 
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NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  general_assoc_s 
(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
lx_conmients 

**  dscrnit_dec1 

IS  INCLUDED  IN: 

DSCRMT  PARAM_DECL 
ITEM 

ALL  OECL 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  OSCRMT_PARAM_DECL) : 

as_source_name_s  ~  :  source_name_s 

as'exp  :  EXP 

as'name  :  NAME 

(INHERITED'FROM  ALLJOURCE): 

lx_srcDOS  :  source_position 

lx_comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

dscrmt_dec1_s.as_list  (Seq  Of] 

**  dscrmt_dec’_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_Iist  :  Seq  Of  dscrmt  decl 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  :  source_position 

1x_comments  :  comments 

IS  the  declared  type  OF: 

PPI\/ATE_SPEC.sm_discriminant_s 
incomo]ete.sm_discriminant_5 
record.sm_discr''minant_s 
type_dec 1 . as_dscrmt_dec 1 _s 

**  DSCRMT_PARAM_DECL 

CLASS  MEMBERS: 

dscrmt_decl 

PARAM 

in 

in_out 

out 

IS  INCLUDED  IN: 

ITEM 

ALL_DECL 
ALL  SOURCE 


:  generaI_assoc_s 

:  source_position 
:  comments 
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NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_source_name_s 
as~exp 
as'name 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx~conments 

**  entry 

IS  INCLUDED  IN: 

SUSP  ENTRY_HEA0ER 
HEADER 
ALL_SOURCE 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_discrete  range  :  DISCRETE  RANGE 

(INHERITED  FROM  SUBP_ENTRY_HEADER) : 

as_paratii  s  :  param  s 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  :  source_pos 'I t ion 

lx_comtnents  :  comments 

**  entry_call 

IS  INCLUDED  IN; 

CALL  STM 

STM  WITH  NAME 

STM" 

STM  ELEM 

all'source 

NODE  ATTRIBUTES; 

(INHERITED  FROM  CALL_STM): 

as_general_assoc_s  :  general_assoc_s 

sm"normal ized  param  s  :  exp_5 

(INHERITED  FROM  STM_WTTH_NAME ) : 

as_name  :  NAME 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  ;  50urce_posi tion 

lx_comments  :  comments 

**  entry_id 

IS  INCLUDED  IN: 

SOURCE_NAME 
DEF  NAME 
ALL'SOURCE 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
sm_spec 
sm_address 

(INHERITED  FROM  DEF_NAME): 

Ix_symrep 


:  HEADER 
:  EXP 

:  symbol _rep 


:  source  name  s 
:  EXP  " 

:  NAME 

:  source_position 
:  comments 
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(INHERITED  FROM  ALL_SOURCE); 
lx_srcpos 
Ix'comments 


**  ENTRYJTM 

CLASS  MEMBERS; 

cond_entry 
timed  entry 
IS  INCLUDED  IN: 

STM 

STM  ELEM 
ALL"SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_stm_si 

as~st(n_s2 

(INHERITED'FROM  ALL_S0URCE): 
1x_srcpos 
Ix'comments 


**  ENUM_LIT£RAL 

CLASS  MEMBERS: 

enumeration_id 
character  id 
IS  INCLUOEO  IN; 

OBJECT  NAME 
SOURCE'NAME 
DEF  NAME 
ALL~SOURC£ 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
sni_pos 
sm_rep 

(INHERITED  FROM  OBJECT_NAME ) : 
sm_obj  type 

(INHERITED  FROM  0EF_NAME): 
lx  symrep 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 

enum  literal  s.as  list  [Seq 


**  enum_l iteral_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_l ist 

(INHERITED  FROM  ALL_SOURCE): 


:  source_position 
:  conments 


;  stm_s 
:  stm_s 

:  source_position 
:  comments 


:  Integer 
:  Integer 

:  TYPE_SPEC 

;  symbol _rep 

:  source_posi tion 
:  comments 

Of] 


:  Seq  Of  ENUM_LITERAL 
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lx_srcpos  ;  sburce_posit1on 

1x~comments  :  convnents 

IS  THE  DECLARED  TYPE  OF: 

enumerat  ion.  sin_l  i  teral  _s 
enumerat ion_def . as_enui_I 1 tera l_s 

**  enumeration 

IS  INCLUDED  IN: 

SCALAR 

NON  TASK 

FULL  TYPE  SPEC 

DERIVABLE~SPEC 

TYPEJPEC" 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_li teral  s  :  enum  literal  s 

(INHERITED  FROM  SCALAR): 

sm_range  :  RANGE 

cd_impl  size  :  Integer 

(INHERITED  FROM~NON_TASK) : 

sni_base  type  :  TYPE  SPEC 

(INHERITED  FROM~DERIVABLE_SPEC) : 

sm_derived  ~  :  TYPE_SPEC 

sm~is  anonymous  :  Boolean 

♦*  enumerat ion_def 

IS  INCLUDED  IN: 

TYPE  OEF 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_enum  literal_s 
(INHERITED  FROM'ALLJOURCE)  : 
lx_srcpos 
.  lx~comments 

**  enumeration_id 

IS  INCLUDED  IN: 

ENUM  LITERAL 
OBJECT  NAME 

source“name 

DEF_NAME 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ENUM_LITERAL) : 
sm_pos 
sm_rep 

(INHERITED  FROM  OBJECT_NAME) : 
sm_obj_type 

(INHERITED  FROM  0EF_NAME): 
lx_symrep 


:  Integer 
:  Integer 

:  TYPE_SPEC 

:  symbol _rep 


:  enum_l iteral_s 

:  source_position 
:  comments 
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(INHERITED  FROM  ALLJQURCE): 
lx_srcpos 
lx  comments 


**  except 1on_decl 

IS  INCLUDED  IN: 

ID  S  DECL 

deCl“ 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  IO_S_OECL): 

as  source  name  s 
(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx”comments 


**  exception_id 

IS  INCLUDED  IN: 

SOURCE_NAME 
DEF  NAME 
ALL  jOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC); 

sm  renames  exc 
(INHERITED'FRQM  OEFJAME): 
lx  symrep 

(INHERITED'FROM  ALL_SOURCE): 
1x_srcpos 
lx~comments 


**  exit 

.IS  INCLUDED  IN: 

STM_WITH_EXP_NAME 

5TM_WITH_EXP 

STM 

STMJLEM 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  stm  : 

(INHERITED'FROM  STM_WITH_EXP_NAME ) 
as  name 

(INHERITED'FROM  STM_WITH_EXP) : 

as  exp  ~  “  : 

(INHERITED'FROM  ALL_SOURCE): 

lx_srcpos  : 

Ix'comments  : 


source_position 

comments 


source_name_s 

source_position 

comments 


NAME 

symbol _rep 

SOUrce_position 

comments 


STM 

NAME 

EXP 

source_position 

comments 


**  EXP 
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CLASS  MEMBERS: 
void 
NAME 
EXP  EXP 
DESIGNATOR 
NAME  EXP 
EXP_VAL 

subtype_al locator 
qua!  ifiid_anocator 
AGG  EXP 
USE0_0BJECT 
USED  NAME 
NAME'VAL 

an 
slice 
indexed 
Short_circuit 
numeric  literal 
EXP_VALjXP 
nulT_access 
aggregate 
string_l iteral 
used_char 
used~object_id 
used'op 
used~natne_id 
attribute” 
selected 
function  call 
MEMBERSHIP 
QUAL_C0NV 
parenthesized 
range_rnembership 
type_menibership 
conversion 
qualified 
IS  INCLUDED  IN: 

GENERAL_ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL  SOURCE): 

lx_srcpos  ”  :  source_position 

lx_comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 
comp_rep.as_exp 
al ignment.as_exp 
NAMEO_REP.as_exp 
entry”id.sm_address 
task_spec.sm_storage_size 
.sm”si2e 
.sm_address 

SUBPROG_PACK_NAME .sm^address 
whi le.as_exp 
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TEST  CLAUSE. as_exp 
STM  WITH  EXP. as  exp 
EXP“VAL_fXP.as_exp 
shor t_cTrcu i t . as_exp I 
.as~exp2 

NAMED_ASSOC.as_exp 
attr1bute.as_exp 
exp_s.as_list  (Seq  Of] 
access. si_stora9e_size 
choice  exp. as  exp~ 
OSCRMT~PARAM  OECL.as  exp 
REAL_C5NSTRATNT.as_exp 
range_attribute.as~exp 
rangeTas_expl 
.as_exp2 

UNCONSTRAINED. sm_size 
VC  NAME.sm  address 
INTT  OBJECT_NAME.sm  init  exp 
EXP  DECL.as_exp 


**  EXP_DECL 

CLASS  MEMBERS: 

OBJECT_DECL 
number~dec1 
constant_decl 
variable'decl 
IS  INCLUDED  IN:  " 

ID  S  DECL 
DECL~ 

ITEM 

ALL  DECL 

allIsource 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  exp  :  EXP 

(INHERITED~FROM  ID_S_OECL): 

as_sour*ce_nanie_s  :  source_name_s 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  :  source_position 

lx  comments  :  comments 


**  EXPJXP 

CLASS  MEMBERS: 

EXP_VAL 

subtype_al locator 

qualified  allocator 

AGGJXP 

short_circuit 

numerTc_literal 

EXP_VAL_EXP 

nun_access 

aggregate 
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string  literal 
MEMBERSHIP 
QUAL_C0NV 
parenthesized 
range_membership 
type_inenibership 
convirsion 
qualified 
IS  INCLUDED  IN: 

EXP 

.-s  GENERAL  ASSOC 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  exp  type 

(INHERITE0“FR0M  ALL_SOURCE): 
lx_srcpos 
Ix'cofnments 

**  exp_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  list  :  Seq  Of  EXP 

(INHERITED'FROM  ALLJOURCE): 

lx_srcpQS  :  source_position 

Ix'comrents  :  coirments 

•  IS  THE  DECLARED  TYPE  OF: 

function  call .stn_normal ized_param_s 
CALL_STM7sni_normil  ized_param_s 
indexed. as_exp_s 

constra  i  ned_record .  sm_nornia  1  i  zed_dscrmt_s 

**  EXP_VAL 

CLASS  MEMBERS: 

snort_circuit 
nume’'ic_i  ite’'al 
EXP_VAL_EXP 
null  access 
MEMBERSHIP 
QUAL_C0NV 
parenthesized 
range_membe''ship 
type_ineiiibership 
convirsion 
qualified 
IS  INCLUDED  IN: 

EXPJXP 

EXP 

GENERAL  ASSOC 


:  TYPE_SPEC 

:  source_position 
:  conments 
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ALL  SOURCE 
NODE  ATTRIBUTES: 
(NODE  SPECIFIC): 


sm  value 

(INHERITEQ-FROM  EXPJXP): 
stn  exp_type~ 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


*♦  EXP_VAL_EXP 

CLASS  MEMBERS; 

MEMBERSHIP 
QUAL_C0NV 
parenthesized 
range_meinbership 
type_iembership 
conversion 
qualified 
IS  INCLUDED  IN: 

EXP  VAL 
EXP  jXP 
EXP 

GENERAL  ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  exp 

(INHERITED'FROM  EXP_VAL): 
sm  value 

(INHERITED'FROM  EXPJXP): 
sm  exp  type” 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 

**  fixed 

IS  INCLUDED  IN: 

real 

SCALAR 

NONJASK 

FULL  TYPE  SPEC 

OERIVABLE'SPEC 

TYPEJPEC” 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

cd_impl_smal 1 
(INHERITED  FROM  REAL): 
sm  accuracy 

(INHERITED'FROM  SCALAR); 
sm_range 
cd_impl_size 


:  value 

:  TYPEJPEC 

:  source_position 
:  conments 


;  EXP 

:■  value 

:  TYPEJPEC 

:  source_position 
:  comments 


:  value 

:  value 

:  RANGE 
;  Integer 
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(INHERITED  FROM  NONJASK): 

sm  base_typi  : 

(INHERITED"FROM  DERIVABLEJPEC) ; 

sm_(lerived  : 

sm~is  anonymous  : 


**  f ixed_constraint 

IS  INCLUDED  IN: 

REAL  CONSTRAINT 
CONSTRAINT 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  REAL_CONSTRAINT) 
sm_type_spec 
as'exp 
as~range 

(INHERITED'FROM  ALL_SOURCE): 
1x_srcpos 
lx  comments 


fixed_aef 

IS  INCLUDED  IN: 

CONSTRAINED  DEF 
TYPE  DEF 

ALL  Source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  CONSTRAINEO_DEF) ; 
as  constraint  : 

(INHERITED'FROM  ALL_SOURCE): 

lx_srcpos  ”  : 

Ix'comments 

**  float 

IS  INCLUDED  IN: 

REAL 
SCALAR 
NON  TASK 
FULL_TyPE_SPEC 
DERIVABLE  SPEC 
.  TYPE  SPEC" 

NODE  ATTRIBUTES: 

(INHERITED  FROM  REAL): 
sm  accuracy 

(INHERITED'FROM  SCALAR): 
sni_range 
cd^impl  size 

(INHERITED  FROM"n0N_TASK) : 
sm  base  type 

(INHERITED"FR0M"DERIVA8LE_SPEC): 
sm_deri ved 
sm_is_anonymous 


TYPEJPEC 

TYPEJPEC 

Boolian 


TYPE  SPEC 
EXP  ~ 

RANGE 

source_position 

comments 


CONSTRAINT 

source_position 

comments 


:  value 

:  RANGE 
:  Integer 

:  TYPE_SPEC 

:  TYPEJPEC 
:  Boolean 
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**  f 1oat_constraint 

IS  INCLUDED  IN: 

REAL  CONSTRAINT 

constraint 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  REAL_CONSTRAINT) 
sin_type_spec~ 
as~exp 
as'range 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'cotnments 


**  float_def 

IS  INCLUDED  IN: 

CONSTRAINED  DEF 
TYPE_DEF 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  CONSTRAINED_OEF) : 

as  constraint  : 

(INHERITED“FROM  ALLJOURCE): 

lx_srcpos  ~  : 

lx~comments  : 


**  for 


IS  INCLUDED  IN: 

FOR  REV 
ITERATION 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  FORJEV): 
as_source_name 
asjiscrete  range 
(INHERITED  FROM  ALLJOURCE): 
]x_srcpos 
1 X  comments 

**-  FORJEV 

CLASS  MEMBERS: 
for 

reverse 
IS  INCLUDED  IN: 

ITERATION 
A*.LJ0URCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  source  name 


TYPE  SPEC 
EXP  ■ 

RANGE 

source_position 

comments 


CONSTRAINT 

sourcejosition 

comments 


SOURCEJAME 
DISCRETE  JANGE 

source_position 

comments 


:  SOURCE  NAME 
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as  discrete  range 
(INHERITED~FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 

*♦  formal_dscrt_def 

IS  INCLUDED  IN: 

TYPE  DEF 

allJource 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 

**  fonnal_f ixed_def 

IS  INCLUDED  IN: 

TYPE_0EF 

ALL_SOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  forma1_f loat_def 

IS  INCLUDED  IN: 

TYPE_0EF 
ALL  SOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 

**  forma1_integer_def 

IS  INCLUDED  IN: 

TYPE_DEF 

ALLJOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ixjoimnents 

**  FULLJYPEJPEC 

CLASS  MEMBERS: 

task_spec 

NONJASK 

SCALAR 

CONSTRAINED 

UNCONSTRAINED 

enumeration 


:  DISCRETE_RANGE 

:  source_position 
:  comments 


:  source_position 
:  comments 


:  source_oosition 
:  comments 


:  source_position 
:  comments 


:  source_position 
:  comments 
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REAL 

integer 

constrained_array 
constra i ned_access 
constra 1 ned'record 
UNCONSTRAINED_COMPOS ITE 
access 
float 
fixed 
array 
record 
IS  INCLUDED  IN: 

DERIVABLEJPEC 
TYPEJPEC 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DERIVABLE_SPEC) ; 
sm_derived 
sni~is_anonymous 

function_ca1 1 

IS  INCLUDED  IN: 

NAME_VAL 
NAME  EXP 
NAME” 

EXP 

GENERAL_ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_general_assoc_s 
sm”norma1  i2ed__pafam_s 
lx  prefix 

(INHERITED'FROM  NAME_VAL): 
sm  value 

(INHERITED’FROM  NAMEJXP): 
as_name 
sin3exp_type 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


TYPEJPEC 

Boolean 


general_assoc_s 

exp_s 

Boolean 

value 

NAME 

TYPEJPEC 

source_Dcsition 

comments 


function  id 


IS  INCLUDED  IN: 

SUBPROGJAME 
SUBPROG_PACK_NAME 
NON  TASK  NAME 
UNITJAME 
SOURCE_NAME 
DEF  NAME 
ALL’SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBPROG  NAME] 
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I 


S(ii_is_1nline  :  Boolean 

sm~interface  :  PREDEF  NAME 

(INHERITED"FROM  SUBPROG_PACK_NAME) : 

sin_unit_desc  ~  ;  UNIT_DESC 

sm'addriss  :  EXP 

(INHERITEO'FROM  NON_TASK_NAME) : 

stn  spec  :  HEADER 

(INHERITED'FROM  UNIT  NAME); 

sm  first  ~  :  OEF  NAME 


(INHERITED  FROM  DEF_NAME): 

lx  symrep  ;  symbol  rep 

(INHERITEO'FROM  ALL  SOURCE): 

lx_srcpos  :  source_position 

Ix^comments  :  comments 


**  function_spec 

IS  INCLUDED  IN: 

SUBP  ENTRY_HEA0ER 
HEADER 
ALL_S0URCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_name  :  NAME 

(INHERITED  FROM  SURP_ENTRY_HEADER) : 

as  param  s  :  param  s 

(INHERITEO'FROM  all  SOURCE): 

lx  srcpos  ~  :  •source_position 

1x"comments  :  comments 

**  GENERAL_ASSOC 


CLASS  MEMBERS: 

NAMED  ASSOC 

EXP 

named 

assoc 

void 

NAME 

EXPJXP 

DESIGNATOR 

NAMEJXP 

EXP_VAL 

sub type_al locator 

qualifiid  allocator 

AGG  EXP 

USED  OBJECT 

USED'NAME 

NAME_VAL 

a1 1 

slice 

indexed 

short_circuit 

numeric  literal 
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EXP_VAL_EXP 
nulT_access 
aggregate 
string_l iteral 
used_char 
used_object_id 
used_op 
used~name_id 
attribute* 
selected 
function_can 
MEMBERSHIP 
QUAL_C0NV 
parenthesized 
range_membersH i p 
type_membership 
conversion 
qualified 
IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  ~  :  source_position 

Ix'comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

general_assoc_s.as_list  [Seq  Of] 

**  general_assoc_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  list  :  Seq  Of  GENERAL  ASSOC 

(INHERITED'FROM  ALL_S0URCE): 

lx_srcpos  ~  :  source_posi t ion 

Ix'comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

instantiat ion. as_general_assoc_s 
function_cal 1 . as_general_assoc_s 
CALL_STMTas_general_assoc_s 
aggregate . as_generaT_assoc_s 
. sm~norraal i zed_comp_s 
dscrmt_constfaint.as_general_assoc_s 
pragma. as_genera1_assoc_s 


**  generic_decl 

IS  INCLUDED  IN: 

UNIT  OECL 
ID_DECL 
DECL 
ITEM 
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ALL  OECL 
ALL"SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  1tem_s 

(INHERITED'FROM  UNIT_0ECL): 
as_header 

(INHERITED  FROM  IO_OECL): 
as  source_name 

(INHERITED~FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  generic_id 

IS  INCLUDED  IN: 

NON_TASK_NAME 

UNIT_NAME 

SOURCE_NAM£ 

0EF_NAME 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_generic_param_s 
sm_is_inl ine 
sm~body 

(INHERITED-FROM  NON_TASK_NAME) : 
sm  spec 

(INHERITED'FROM  UNIT_NAME); 
sm  first 

(INHERITED‘FR0M  DEF_NAME): 
lx  symrep 

(INHERITED'FROM  ALL_S0URCE): 
lx_srcpos 
1 x_comments 

**  GENERIC_PARAM 

CLASS  MEMBERS: 

name_def au i t 
no_default 
box  default 
IS  INCLUDED'IN: 

UNIT_KIN0 
UNIT_DESC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  goto 


:  item_s 

:  HEADER 

:  SOURCE_NAME 

:  source_position 
:  comments 


:  item_s 
:  Boolean 
:  BODY 

:  HEADER 

:  0EF_NAME 

:  symbol _rep 

:  source_position 
:  comments 


:  source_position 
:  comments 


IS  INCLUDED  IN: 
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STM  WITH  NAME 
STM" 

STM  ELEM 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  STM_WITH_NAME) : 

as  name  ~  ~  :  NAME 

(INHERITEO"FROM  ALLJOURCE): 

lx_srcpos  :  source_position 

1x~comments  :  conwnents 

*♦  HEADER 

CLASS  MEMBERS: 

SUBP_ENTRY_HEADER 

packige_spic 

procedure_spec 

function_spec 

entry 

IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURC£): 

lx  srcpos  :  source_position 

lx~comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 
entry_id,sffl_spec 
subprogram  body .as  header 
NON_TASK_NAME . sm_spec 
UN[T_OECL.as_header 

*•*  ID_0ECL 

CLASS  MEMBERS: 

type_decl 
UNIT_0ECL 
task_decl 
subtype  dec! 

SIMPL£_RENAME_OECL 
generic  dec! 

NON_GENERIC_OECL 
renames_obj~dec1 
renames~exc_decl 
subprog3entry_decl 
package'decl 
IS  INCLUDED  IN:" 

DECL 

ITEM 

ALL  DECL 

all"source 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_source_name  :  SOURCE  NAME 

(INHERITED  FROM  ALLJOURCE): 
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1x_srcpos  :  source_position 

lx~coinments  :  coinments 

**  ID_S_DECL 


:  source_name_s 

:  source_position 
:  comments 


**  if 

IS  INCLUDED  IN: 

CLAUSES  STM 
STM 

STM  ELEM 
ALLjOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  CLAUSESJTM) : 
as_test_clause_e1em_s 
as  stm_s 

(INHERITEO~FROM  ALLJOURCE); 
lx_srcpos 
1 x_CQmments 

**  imD]icit_not  eq 

IS  INCLUDED  IN: 

UNIT_DESC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
sm_equal 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 

**  in 


:  SOURCE_NAME 

:  source_position 
:  comments 


:  test_ciause_elem_s 
:  stm_s 

:  source_oosition 
:  comments 


CLASS  MEMBERS: 

EXP_OECL 

defirred_constant_decl 
exception  decl 

object_oeCl 

number_dec1 
constant_decl 
variab  leaded 
IS  INCLUDED  IN: 

DECL 

ITEM 

ALL_OECL 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_source_name_s 
(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx~comments 
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IS  INCLUDED  IN: 

PARAM 

DSCRMT  PARAM  DECL 
ITEM 

ALL  DECL 
ALL~SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

lx  default  :  Boolean 

( INHERITE0“FR0M  OSCRMT_PARAM_OECL) ; 

as_source_name~s  :  source_name_s 

as~exp  ~  :  EXP 

as~name  :  NAME 


(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  ~  :  source_position 

lx~comments  :  comments 


n  id 


IS  INCLUDED  IN: 

PARAM  NAME 
INIT_OBJECT_NAME 
OBJECTJAME 
SOURCE  NAME 
OEF  NAME 
ALL"S0URCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  PARAM  NAME): 

sm  first  ~  :  DEF_NAME 

( I NH  E  R I TE  D‘FROM  INI T_08 J£CT_NAME ) ; 


sm  imt  exp 

( INHERITED"FR0M'08JECT_NAME) : 
sm  obj  type 

(INHERITE0"FR0M  0EF_NAME): 
lx  symrep 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


EXP 

TYPEJPEC 

symbol _rep 

source_position 

comments 


n_op 


IS  INCLUDED  IN: 

MEMBERSHIP  OP 
ALL  SOURCE" 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


source_position 

comments 


in_out 

IS  INCLUDED  IN: 

PARAM 

DSCRMT  PARAM  DECL 
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ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DSCRMT  PARAM  DECL] 


as_source_nafne_s 

as~exp 

as'name 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  in  out_id 

IS  INCLUDED  IN: 

PARAM  NAME 
INIT  OBJECT  NAME 
OBJEi^T  NAME" 

source"name 

OEF  NAME 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  PARAM_NAM£): 
sm  first 

(INHERITEO'FROM  INIT_OBJECT_NAME 
sm  init  exp 

(INHERITED”FR0M~08JECT_NAME): 
sm  obj  type 

(INHERITEO'FROM  DEFJAME): 
lx  symrep 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 

**  incomplete 

IS  INCLUDED  IN: 

TYPEJPEC 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  discriminant  s  : 


**  index 

IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 
sm'type  spec 

( INHERITED'FR0M"ALL_S0URCE) : 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 


source  name  s 

EXP 

NAME 

source_position 

comments 


DEF_NAME 

*EXP 

TYPEJPEC 

symbol _rep 

source_position 

comments 


dscrmt  dec!  s 


NAME 

TYPEJPEC 

source_position 

comments 
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1ndex_s.as_11st  [Seq  Of] 

**  1ndex_constra1nt 

IS  INCLUDED  IN: 

CONSTRAINT 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  discrete  range  s 
(INHERITED'FROM  ALLJOURCE): 
1x_srcpos 
Ix'comments 


**  index _s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NOOE  SPECIFIC): 
as_l ist 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx~cotnments 
IS  THE  DECLARED  TYPE  OF: 
array. sm_index_s 
unconstrai ned_array_def . as 


**  indexed 

IS  INCLUDED  IN: 

NAME  EXP 

NAME' 

EXP 

general_assoc 

ALL  SOURCE 
NOOE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_exp_s 

(INHERITED  FROM  NAME_EXP): 
as_name 
sm'exp  type 

(INHERITED'FROM  ALL_SOURCE): 
Ix_srcpos 
lx  comments 


**  INIT_OBJECT_NAME 

CLASS  MEMBERS: 

VC_NAME 
number_id 
COMP  NAME 
PARAM  NAME 


:  discrete_range_s 

:  source_position 
:  comments 


:  Seq  Of  index 

:  source_position 
:  comments 

index  s 


:  exp_s 

:  NAME 
:  TYPE_SPEC 

:  source_position 
:  comments 
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variab1e_1d 

constant~id 

component_id 

d1scriminant_id 

1n_id 

out_id 

In  out  id 

IS  INCLUDED  INT 

OBJECT  NAME 
SOURCElNAME 
DEF  NAME 

all'source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_init  exp 

(INHERITED  FR0M"0BJECT_NAME) : 
sm  obj_type 

(INHERITED"FR0M  DEF_NAME): 
lx  symrep 

(INHERITED'FROM  ALLJOURCE): 
1x_srcpos 
lx_comments 

*♦  instantiation 

IS  INCLUDED  IN: 

RENAME  INSTANT 
UNIT  KIND 
UNIT~DESC 

ALL  Source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_general_assoc_s 
sni'decl  s 

(INHERITED  FR0M“RENAME_INSTANT) : 
as_name 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


**  integer 


IS  INCLUDED  IN: 

SCALAR 
NONJASK 
FULL  TYPE  SPEC 
DERIVABLE'SPEC 
TYPE  SPEC' 

NODE  ATTRIBUTES: 

(INHERITED  FROM  SCALAR): 
sm_range 
cd~imp1_size 

(INHERITED'FROM  NONJASK): 
sm_base_type 


EXP 

TYPE_SPEC 

symbol _rep 

source_position 

comments 


:  general_assoc_s 
:  decl_s 

:  NAME 

:  source_DOSition 

:  comments 


:  RANGE 
:  Integer 

:  TYPE  SPEC 
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(INHERITED  FROM  DERIVABLE_SPEC): 
sm_derived 
sm~is  anonymous 


**  integer_def 

IS  INCLUDED  IN: 

CONSTRAINEO_DEF 
TYPE  DEF 

ALL  Source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  CONSTRAINED_DEF) 
as_constraint 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


**  ITEM 


CLASS  MEMBERS: 

DSCRMT  PARAM_0£CL 
DECL 

SUBUNITJODY 
dscrmt  dec! 

PARAM  ~ 

ID  S_OECL 
ID'DECL 

nuTi  comp  dec! 

REP  ■ 
use_pragma 

subprogram_body 

task_body 

package_body 

in 

in_out 

out 

EXP_0£CL 

defirred_constant_dec1 

exception_decl 

type_deci 

UNIT_0ECL 

task_dec1 

subtype  dec! 

SIMPLE_RENAME_OECL 

void 

named_rep 

record_rep 

use 

pragma 
0BJECT_0ECL 
number_dec1 
generic  decl 
N0N_GENERIC_DECL 
rename s_obj_decl 


TYPEJPEC 

Boolean 


:  CONSTRAINT 

:  source_position 
:  comments 


DIANA  Reference  Manual  Draft  Revision  4 
DIANA  CROSS-REFERENCE  GUIDE 


Page  A- 76 


renames_exc_decl 
length_inum”rep 
address 
constant_decl 
var1ab1e~decl 
subprog_intr>_decl 
package  deci 
IS  INCLUDED  IN:" 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
1x_srcpos 
1x"comments 
IS  THE  DECLARED  TYPE  OF: 

itein_s.as_1ist  (Seq  Of] 

**  i tem_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  list 

(INHERITED"FROM  ALLJOURCE): 
1x_srcpos 
lx"cofnments 
IS  THE  DECLARED  TYPE  OF: 

gener  i  c_i  d .  sin_gener  i  c_param, 
gener 1 c^dec I . as_i tem_s 
b 1 ock_body . as_i tem_s~ 

**  ITERATION 

CLASS  MEMBERS: 
void 
FOP_PEV 
while 
for 

reverse 
IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx"comments 
IS  THE  DECLARED  TYPE  OF; 

1oop.a5_iteration 

**  iteration_id 

IS  INCLUDED  IN: 

OBJECT  NAME 


source_position 

connents 


Seq  Of  ITEM 

SOurce_position 

comments 


:  source_position 
:  comments 
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SOURCE  NAME 
OEF  NAME 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  OBJECT_NAME) : 
sm  obj_type 

(INHERITE0"FR0M  0EF_NAME): 

1 X  symrep 

(INHERITE0~FR0M  ALLJOURCE): 
Ix_srcpos 
1x~comments 


**  1_private 

IS  INCLUDED  IN: 

PRIVATE  SPEC 
DERIVABLE  SPEC 
TYPE  SPEC" 

NODE  ATTRIBUTES: 

(INHERITED  FROM  PRIVATEJPEC) : 
sm_di scrimi nant_s 
sm  type_spec 

(INHERITE0"FR0M  DERIVABLE_SPEC) : 
sw_derived 
sm"is_anonymous 


*■*  l_private_def 

IS  INCLUDED  IN: 
type  OEF 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
1x_comments 

**  l_pri vate_type_id 

IS  INCLUDED  IN: 

TYPE  NAME 
SOURCE_NAME 
DEF  NAME 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  TYPE_NAME): 
sm_type  spec" 

(INHERITED  FROM~OEF_NAME) : 
lx  symrep 

(INHERITEO"FROM  ALL_SOURCE): 
lx_srcpos 
1x"comments 


**  label  id 


TYPEJPEC 

symbol _rep 

source_position 

comments 


:  dscrmt_decl_s 
:  TYPEJPEC 

:  TYP£_SPEC 
:  Boclian 


:  source_pasition 
:  comments 


:  TYPE_SPEC 

:  symbol _rep 

:  source_position 
:  comments 


DIANA  Reference  Manual  Draft  Revision  4 

DIANA  CROSS-REFERENCE  GUIDE 


Page  A- 78 


IS  INCLUDED  IN: 

LABEL  NAME 
SOURCf  NAME 
OEF  NAME 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  LABELJAME); 
sm  stffl 

(INHERITED'FROM  DEF_NAME): 
lx  symrep 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


**  LABELJAME 

CLASS  MEMBERS: 

1abel_id 
b1ock_1oop  id 
IS  INCLUDED  IN: 

SOURCE  NAME 
0£F_NAME 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
stn  stm 

(INHERITE0"FR0M  OEFJAME): 
lx  symrep  ~  ' 

(INHERITED’FROM  ALLJOURCE): 
?x_srcpos 
lx~comments 


**  labeled 

IS  INCLUDED  IN: 

STM 

STMJLEM 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_source_name_s 

as_stm 

as_pragma_s 

(INHERITED  FROM  ALLJOURCE): 
Ixjrcpos 
lx~comments 


**  length_enum_rep 

IS  INCLUDED  IN: 

NAMED  REP 
REP 
DECL 
ITEM 


:  STM 

:  symbol _rep 

:  source_position 
:  comments 


:  STM 

;  symbol _rep 

;  source_pos i t ion 
:  comments 


:  source_name_s 
:  STM 

:  pragma_s 

:  source_position 
:  comments 
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ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  NAMED^REP): 
as_exp 

(INHERITED  FROM  REP): 
as  name 

(IMHERITED"FROM  ALL_SOURCE): 
lx_srcpos 
Ix'coimnents 

**  loop 

IS  INCLUDED  IN: 

BLOCK  LOOP 
STM 

STM_ELEM 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_iteration 
as  stm  s 

(INHERITED'FROM  BLOCK_LOOP): 
as  source_name 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 


**  MEMBERSHIP 

CLASS  MEMBERS: 

range_membership 
type  membership 
IS  INCLUDED  TN: 

EXP  VALJXP 
EXP'VAL 
EXP'EXP 
EXP~ 

GENERAL_ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

as  membership_op 

(INHERITED’FROM  EXP_VAL_EXP) : 
as_exp 

(INHERITED  FROM  EXP_VAL): 
sm_va1ue 

(INHERITED  FROM  EXP_EXP): 
sm_exp_type 

(INHERITED  FROM  ALL_SOURCE): 
1x_srcpos 
lx  comments 


:  EXP 
:  NAME 

:  source_position 
:  comments 


:  ITERATION 
;  stm_s 

:  SOURCE_NAME 

:  source_position 
:  comments 


MEMBERSHIP_OP 

EXP 

value 

TYPE_SPEC 

SOurce_position 

comments 


**  MEMBERSHIP  OP 
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CLASS  MEMBERS: 
in_op 
not  in 
IS  INCLUOED'IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL  SOURCE): 

lx_srcpos  ~  :  source_position 

Ix'comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

MEMBERSHIP. as  membership_op 


**  NAME 

CLASS  MEMBERS: 

DESIGNATOR 

NAMEJXP 

void 

USED  OBJECT 
USED  jAME 
NAME_VAL 

an 

slice 

indexed 

,  used_char 

used_object_id 
used'op 
used~name_id 
attribute 
selected 
function_can 
IS  INCLUDED  IN: 

EXP 

GENERAL_ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE); 

lx  srcpos  :  source_position 

1  xj^comments  :  comments 

IS  the  declared  type  OF: 
comp_rep.as_name 
REP.is_name 
name_dif au 1 t . as_name 
except  i  on_i  d .  sm_renanies_exc 
subuni t.as_name 
name_s.as_Tist  [Seq  Of] 
accept. as  name 
RENAME_INSTANT . as_name 
renames  obj_decl.as_type  mark  name 
SIMPLE_RENAME_DECL.as_name 
deferred_constant_decl .as_name 
function  spec. as  name 
STM  WITH“NAME.as~name 
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STM_W I T H_E X P_NAME . as_name 
QUAL_C0NV . as'name 
type  member ship.as_ndffle 
NAME~EXP.as_name 
variant  part.asname 
DSCRMT_PARAM_DECL . as_name 
index. as_name 
r ange_at t r i bu  te . as_name 
subty pe_i nd i cat i on . as_name 

**  name_default 

IS  INCLUDED  IN: 

GENERIC  PARAM 
UNIT  KIND 
UNIT'OESC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 

(INHERITED  FROM  ALL_SOURCE); 
lx_srcpos 
lx_cotnments 

**  NAME_EXP 

CLASS  MEMBERS: 

NAME  VAL 
all  ■ 
slice 
i Pdexed 
dt tribute 
sc’erted 
function  call 
IS  INCLUDED  IN: 

NAME 
EXP 

GENERAL  ASSOC 
ALL_S0URC£ 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_name  :  NAME 

sm~exp_type  :  TYPE  SPEC 

(INHERITE0~FR0M  ALL_SOURCE): 

lx_srcpos  :  source_position 

Ix'comments  :  comments 

**  name_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 


:  NAME 

:  source_posit1on 
:  conmients 
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as_list 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 
with.as_name_s 
abort. as_nami_s 
use.as_name_s 


**  NAME_VAL 

CLASS  MEMBERS: 

attribute 
selected 
function_ca1 1 
IS  included  IN: 

NAMEJXP 

NAME 

EXP 

GENERAL  ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES:  • 

(NODE  SPECIFIC): 

sm  value 

(INHERITED'FROM  NAMEJXP): 
as_name 
sm'’exp  type 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


named 

IS  INCLUDED  IN: 

NAMED_ASSOC 
GENERAL  ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC); 

ds_choice_s 

(INHERITED  FROM  NAMEDJSSOC) : 
as_exp 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  NAMEDJSSOC 

CLASS  MEMBERS: 
named 
assoc 

IS  INCLUDED  IN: 

GENERALJSSOC 
ALL  SOURCE 


:  Seq  Of  NAME 

:  source_position 
:  Comments 


:  value 

:  NAME 
:  TYPEJPEC 

:  source_position 
:  comments 


:  choice_5 

:  EXP 

:  source_position 
:  comments 
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NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  exp 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
lx~cointnents 


*♦  NAMED_REP 

CLASS  MEMBERS: 

1ength_enum_rep 
address 
IS  INCLUDED  IN: 

REP 

DECL 

ITEM 

ALL  DECL 
all"source 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  exp 

(INHERITEO'FROM  REP): 
as  name 

(INHERITEO'FROM  ALL  SOURCE): 
1x_srcpos 
Ix'comments 


**  no_defauU 

IS  INCLUDED  IN: 

GEN£RIC_PARAM 
UNIT  KIND 
UNIT^OESC 
ALL  SOURCE 
NODE  ATTRIBUitS: 

(INHERITED  FROM  ALL^SOURCE): 
Ix_srcpos 
lx  comments 


**  NON_G£NERIC_QECL 

CLASS  MEMBERS: 

subprog_entry_decl 
package_dec1 
IS  INCLUDED  IN: 

UNIT_DECL 

ID_0ECL 

DECL 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  unit  kind 


:  EXP 

:  sour ce_posit ion 
:  comments 


:  EXP 
:  NAME 

:  source_position 
:  comments 


:  source_posi tion 
:  comments 


:  UNIT  KIND 
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(INHERITED  FROM  UNIT_DECL): 
as  header 

(INHERITED'FROM  ID_0ECL): 

as  source  name 
(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 

**  N0N_TASK 

CLASS  MEMBERS: 

SCALAR 
CONSTRAINED 
UNCONSTRAINED 
enumeration 
REAL 
integer 

constrained_array 
constrained_access 
constrained  record 
UNCONSTRAINED_COMPOSITE 
access 
float 
fixed 
array 
record 
IS  INCLUDED  IN: 

FULL  TYPE  SPEC 

derivable'spec  • 

TYPE  SPEC" 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sni_base  type  :  TYPE  SPEC 

(INHERITED  FROM'DERIVABLEJPEC): 

sm  derived  :  TYPE_SPEC 

sm_i s_anonymous  :  Boolean 

**  non_task_name 

CLASS  MEMBERS: 

SUBPROG_PAC<_NAME 
generic  id 
SUBPROG^NAME 
package"id 
procedure_id 
operator_id 
function  id 
IS  INCLUDED  IN: 

UNIT  NAME 
SOURCE_NAME 
DEF  NAME 
ALL  jOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 


:  HEADER 

:  SOURCE_NAME 

:  source_positiori 
:  conments 
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sm  spec 

(INHERITED“FROM  UNIT_NAME): 
sm_f irst 

(INHERITED  FROM  DEF_NAME): 
lx_synirep 

(INHERITED  FROM  ALL_SOURCE): 

1x_srcpos 
Ix^comments 

**  not_in 

IS  INCLUDED  IN: 

MEMBERSHIP_OP 
ALL  SOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FOOM  ALL_SOURCE): 

lx_srcpos  :  source_position 

1  x~co(iiments  :  comments 

**  nun_access 

IS  INCLUDED  IN: 

EXP  VAL 
EXP“EXP 
EXP~ 

GENERAL  ASSOC 
ALL  SOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  EXP_VAL): 
sm  value 

(INHERITEO'FROM  EXPJXP): 
sm  exp  type 

(INHERITED'FROM  ALL_S0URC£): 
lx_srcpos 
1x_comments 

**  null_comp_decl 

IS  INCLUDED  IN: 

DECL 
ITEM 

ALL  DECL 
ALL ^SOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  :  source_position 

lx_comments  :  comments 

**  nun_stm 

IS  INCLUDED  IN: 

STM 

STM  ELEM 
ALL'SOURCE 


:  value 

:  TYPE_SPEC 

:  source_position 
:  comments 


:  HEADER 

;  DEF_NAME 

:  symbol _rep 

:  source_position 
:  comments 
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NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Tx'conments 

**  number_decl 

IS  INCLUDED  IN: 

EXP  OECL 
ID  S  OECL 
deJl" 

ITEM 

ALL_DECL 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  EXP_DECL): 
as_exp 

(INHERITED  FROM  ID_S_0ECL): 
as_source  name_s 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  mjmber_id 

IS  INCLUDED  IN: 

INIT  OBJECT  NAME 
OBJECT  NAME" 

SOURCE'NAME 
■  DEF  NAME 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  INIT JBJECTJAME) 
sm_init  exp  : 

(INHERITED  FROM'OBJECTJAME) : 

sm_obj_type  : 

(INHERITED  FROM  DEFJAME): 

1x  symrep  : 

(INHERITED'FROM  ALLJOURCE): 

lx_srcpos  : 

Ix  comments  : 


**  numeric_1 iteral 

IS  INCLUDED  IN: 

EXP  VAL 
EXPJXP 
EXP 

GENERAL  ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

lx  numrep 

(INHERITEO"FROM  EXPJAL): 


source_posUion 

comments 


EXP 

source_name_s 

source_posUion 

comments 


*EXP 

TYPEJPEC 

symbol _rep 

source_pos i ti on 
comments 


number_rep 
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sm  value 

(INHERITED~FROM  EXPJXP): 
sm  exp_type 

(INHERITED~FROM  ALL_SOURCE): 
lx_srcpos 
lx~comments 

08JECT_0ECL 

CUSS  MEMBERS: 

constant_dec1 
variable'decl 
IS  INCLUDED  IN:  ~ 

EXP  DECL 
rD_5_0ECL 
DECL 
ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBOtES: 

(NODE  SPECIFIC): 

as_type_def 

(INHERITED  FROM  EXP_OECL): 
asexp 

(INHERITED  FROM  ID_S_DECL): 
as  source  name_s 

(INHERITED"FROM  ALLJOURCE): 
lx_srcpos 
lx~cotnments 

**  OBJECTJAME 

CLASS  MEMBERS: 

INIT_08JECT  NAME 
ENUM_LITERAL 
iteration  id 
VC_NAME 
number  id 
C0MP_NAME 
PARAM_NAM£ 
enurneration_id 
character_id 
variab1e_Td 
constant^id 
component_id 
discriminant_id 
in_id 
out_id 
in  out_id 
IS  INCLUDED  IN: 

SOURCE_NAME 

OEF_NAME 

ALL_S0URC£ 

NODE  ATTRIBUTES: 
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;  value 

:  TYPE_SPEC 

:  source_position 
:  comments 


:  TYP£_DEF 
:  EXP 

:  source_name_s 

:  source_position 
:  comments 
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(NODE  SPECIFIC): 

sm  obj  type 

(INHERITED~FROM  DEF_KAME): 
lx  symrep 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'conments 


:  TYPE_SPEC 

;  symbol _rep 

:  source_position 
:  comments 


operator_id 

IS  INCLUDED  IN: 

SUBPROG  NAME 

SUBPROG'PACK  NAME 

NON  TASK  NAME 

uniTjame 

SOURCE  NAME 

DEF  NAME 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBPROG_NAME) : 

sm_is_inline  :  Boolean 

sm_interface  :  PREDEF  NAME 

(INHERITED  FROM  SU8PR0G_PACK_NAM£) : 

sm_unit_desc  :  UNIT_DESC 

sm'address  :  EXP 

(INHERITED'FROM  NON_TASK_^NAME ) : 

sm  spec  "  :  HEADER 

(INHERITED'FROM  UNIT_NAME): 

sm  first  ~  :  DEF  NAME 

(INHERITEO'FROM  OEFJAME): 

lx  symrep  :  symbol  rep 

(INHERITED'FROM  ALL_S0URC£): 

1x_srcpos  ~  :  source_position 

Ix'comments  :  comments 


**  or  else 


IS  INCLUDED  IN: 

short_circuit_op 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE); 

lx_srcpos  :  source_position 

Ix'comments  :  comments 


out 

IS  INCLUDED  IN: 

PARAM 

DSCRMT  PARAM_0ECL 
ITEM 

ALL  DECL 
ALLJOURCE 
NODE  ATTRIBUTES: 
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*★ 


(INHERITED  FROM  OSCRMT_PARAM_DECL) : 


as_source_name_ 
as_exp 
as~name 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx~comnients 


source_name_s 

EXP 

NAME 

source_position 

comments 


out  Id 


IS  INCLUDED  IN: 

PARAM  NAME 
IN  IT  OBJECT  NAME 
OBJECT  NAME’ 

SOURCEjAME 
DEF  NAME 
ALL’SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  PARAM_NAME): 
sm  first 


1 


DEF  NAME 


(INHERITED  FROM  INIT_08JECT_NAME) : 
sm  init  exp  ’  ~  : 


EXP 


(INHERITED  FROM  OBJECT_NAME) : 
sm  obj_type 

(INHERITED’FROM  DEF_NAME): 

1 X  symrep 

(INHERITED’FROM  ALL_SOURC£): 
lx_srcpos 
Ix’comments 


TYPE_SPEC 

symbol _rep 

source_position 

comments 


package_body 


IS  INCLUDED  IN: 

SUBUNIT  BODY 
ITEM 

ALL_DECL 

ALL_SOURC£ 

NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBUNITJODY) : 


as_source_name 

as’body 

(INHERITED’FROM  ALL_SOURCE): 
lx_srcpos 
Ix’comments 


:  S0URCE_NAME 
:  BODY 

:  source_position 
:  comments 


**  package_decl 

IS  INCLUDED  IN: 

NON_GENERIC_DECL 

UNIT  DECL 

IO_DECL 

DECL 

ITEM 

ALL  DECL 
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ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  NON_GENERIC_DECL) : 

as  unit  kind  ~  :  UNIT  KIND 

( INHERITE0"FR0M“UNIT_DECL) : 

as  header  ~  :  HEADER 


(INHERITED~FROM  I0_0ECL): 

as_source_nanie 
(INHERITED  FROM  ALLJOURCE): 
1x_srcpos 
ix'comments 


:  SOURCE_NAME 

:  source_position 
:  conments 


**  package_id 

IS  INCLUDED  IN: 

SUBPROG_PACK  NAME 
NON  TASK  NAME 
UNIT  NAME 
SOURCE  NAME 
0EF_NAME 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBPROG_PACK_NAME) : 

sm_unit_desc  ~  :  UNIT_0ESC 

sm  address  :  EXP 

(INHERITED"FROM  NON_TASK_NAME) : 
sm  spec 

(INHERITEO'FROM  UNIT_NAME): 
sm_first 

(INHERITED  fROM  OEFJAME): 
lx  symrep 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


:  HEADER 

:  DEFJAME 

:  symbol_rep 

:  source_position 
:  comments 


**  package_spec 

IS  INCLUDED  IN: 

HEADER 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_decl_sl 
as  decl~s2 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx~comments 


:  decl_s 
:  dec1~s 

:  source_position 
:  conments 


**  PARAM 

CLASS  MEMBERS; 
in 

in_out 

out 
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IS  INCLUDED  IN: 

OSCRMT  PARAM_OECL 

ITEM 

ALL  DECL 

all’source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  DSCRMT_PARAM_OECL) 
as_source_nanie_s  ~  : 

as'exp  ~  ~  : 

as'name  : 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  ~  : 

lx~conments  : 

IS  THE  DECLARED  TYPE  OF: 

paratn_s.as_l  1st  [Seq  Of] 


**  PARAM_NAME 

CLASS  MEMBERS: 
in_icl 
out_id 
in_out_icl 

IS  INCLUDED  IN: 

INIT_OBJECT  NAME 
OBJECT  NAME" 

source"name 

DEF  NAME 

all"source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  first  : 

(INHERITED'FROM  INIT_OBJECT_NAME ) 
sm  1n1t  exp  "  "  : 

( I NHER  ITED“FR0M"0BJECT_N.  .,-it ) : 

sm  obj_type  : 

(INHERITEO'FROM  0EF_NAME): 

lx  symrep  "  : 

(INHERITED'FROM  ALL_SOURCE): 

1x_3rcpos  : 

lx  comments  : 


**  param_s 

IS  INCLUDED  IN; 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_l 1st 

(INHERITED  FROM  ALL_SOURCE): 
1x_srcpos 
lx"comments 
IS  THE  DECLARED  TYPE  OF: 

accept. as_param_s 


source  nam€_s 

EXP 

NAME 

source_pos1t1on 

comments 


DEFJAME 

EXP 

TYPEJPEC 

symbol _rep 

source_position 

comments 


Seq  Of  PARAM 

source_pos1t1on 

comments 
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SUBP_ENTRY_HEAOER-as_param_s 


**  parenthesized 

IS  INCLUDED  IN: 

EXP_VAL  EXP 
EXP  VAL~ 

EXPjXP 

EXP 

GENERAL_ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  EXP_VAL_EXP) : 

as_exp  : 

(INHERITED  from  EXP_VAL): 

sm_value  : 

(INHERITED  FROM  EXPJXP): 

sni_exp  type  : 

(INHERITED  FROM  ALL_SOURCE): 

1x_srcpos  : 

lx_comments  ; 

**  pragma 

IS  INCLUDED  IN: 

USE_PRAGMA 

DECL 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_used_name_id 
as  genera ]_assoc_s 
(INHERITED"FROM  ALLJOURCE): 
1x_srcpos 
lx_comments 
IS  ■"HE  DECLARED  TYPE  OF: 

como  rep_pragma.as_pragma 
contixt_pragma.as  pragma 
pragma_s.as_1 ist  TSeq  Of] 
se  1  ect_aU_pragma .  as_pragma 
al ternat i ve_pragma . as_pragma 
s  tm_p  ragma . is_p  r agma 
var i ant_pragma . as_pragma 

**  pragma_id 

IS  INCLUDED  IN: 

PREDEF  NAME 
DEF_NAME 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 


EXP 

value 

TYPEJPEC 

source_pos1t1on 

comments 


used_name_id 

genera1_assoc_s 

source_position 
comments  . 
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sm  argument  i<j_s 
(INHERITED'FROM  OEF'naME): 
lx  symrep 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


**  pragma_s 


IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  list 

(INHERITEO'FROM  ALL_SOURCE): 
lx_srcpos 
lx~cotnments 
IS  THE  DECLARED  TYPE  OF: 

al ignment.as_pragma_s 
compi 1ation_unit-as_pragma_s 
1 abe 1 ed . as_pr agmd_s 
comp_1 ist.as_pragmd_s 


**  PREDEF_NAME 

CLASS  MEMBERS: 

attribute_id 

void 

bitn_operator_id 
argufflent_id 
pragma  id 
IS  INCLUDED  IN: 

DEF  NAME 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DEF_NAME): 
lx  symrep 

(INHERITEO'FROM  ALL_SOURCE): 
lx_srcpos 
lx_comments 
IS  THE  DECLARED  TYPE  OF: 

SUBPROG_NAME .  sin_i  nterf  ace 


**  private 

IS  INCLUDED  IN: 

PRIVATE  SPEC 
DERIVABLE  SPEC 
TYPE_SPEC~ 

NODE  ATTRIBUTES: 

(INHERITED  FROM  PRIVATE_SPEC) : 
sni_discriminant_s 
sm_type_spec 


:  argument_id  s 

:  symbol _rep 

:  source_position 
:  comments 


:  Seq  Of  pragma 

:  source_position 
:  comments 


*:  symbol _rep 

:  source_pcsUinn 

:  comments 


:  dscrmt  decl_s 
:  TYPE  SPEC 
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(INHERITED  FROM  DERIVABLE_SPEC) : 
sm_der 'ved 
sm~is_anonymous 


**  private_def 

IS  INCLUDED  IN: 

TYPE  DEF 

ALL  Source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  PRIVATEJPEC 

CLASS  MEMBERS: 

private 
l_pri vate 
IS  INCLUDED  IN: 

DERIVABLEJPEC 
TYPEJPEC 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_di scriminant_s 
sm~type  spec 

(INHERITEO'FROM'DERIVABLEJPEC): 

sm_derived 

sm~is_anonymous 


**  pri vate_type_id 

IS  INCLUDED  IN: 

TYPE  NAME 
SOURCE  NAME 
DEF_NAME 
ALL  SOURCE 
NODE  ATTRIBUTES; 

(INHERITED  FROM  TYPE_NAME): 
sm  type_spec 

(INHERITED'FROM  0EF_NAME): 
lx  symrep 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
Ix'comments 


**  procedure_can 

IS  INCLUDED  IN: 

CALL_STM 

STM  WITHJAME 

STM~ 

STMJLEM 
ALL  SOURCE 


TYPE_SPEC 

Boolean 


source_p_sition 

comments 


:  dscrmt_dec1  s 
:  TYPE_SPEC 

:  TYPEJPEC 
:  Boolean 


:  TYPE_SPEC 

:  symbol _rep 

:  source_position 
:  comments 
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NODE  ATTRIBUTES: 

(INHERITED  FROM  CALlJTM): 

as_genera1_assoc_s  :  general_assoc_s 

sm~norma1  iie(l_param_s  :  exp  s 

(INHERITED  FROM  STM_WITH_NAME) : 

as  name  :  NAME 

(INHERITEO'FROM  ALL_SOURCE): 

lx_srcpos  :  source_position 

lx~comments  :  comments 

**  procedure_id 

IS  INCLUDED  IN: 

SUBPR0G_NAME 
SUBPROG_PACK  NAME 
NON  TASK_NAME 
UNIT  NAME 
SOURCE_NAME 
DEF  NAME 
ALL'SOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBPROG_NAME) : 

sm_is_inline  ~  :  Boolean 

sm_interface  :  PREDEF  NAME 

(INHERITED  FROM  SUBPROG_PACK_NAM£ ) : 

sm_unit_desc  ~  :  UNIT_DESC 

sm'address  :  EXP 

(INHERITEO'FROM  NON_TASK_NAME ) : 

sm  spec  ~  ~  :  HEADER 

(INHERITED'FROM  UNIT_NAME):  . 

sm  first  :  DEF  NAME 

(INHERITED'FROM  DEF_NAME): 

lx  symrep  :  symbol  rep 

(INHERITED'FROM  ALL_SOURCE): 

lx_srcpos  :  source_position 

lx_comments  :  comments 

**  orocedure_soec 

IS  INCLUDED  IN: 

SUBP_£NTRY_HEADER 

HEADER 

ALLJOURCE 

NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBP_ENTRY_HEAOER) : 

as_param_s  ~  :  param_s 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  :  source_position 

Ix'comments  :  comments 

**  QUALJONV 

CLASS  MEMBERS: 

conversion 
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•kir 


qualified 
IS  INCLUDED  IN: 

EXP_VAL  EXP 
EXP  VAL~ 

EXPjXP 

EXP 

general  assoc 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  name 

(INHERITED'FROM  EXP_VAL_EXP) : 
as_exp 

(INHERITED  FROM  EXP_VAL): 
sm_value 

(INHERITED  FROM  EXPJXP): 
sm  expjype 

(INHERITED'FROM  ALLJOURCE): 
1x_srcpos 
lx  comments 


:  NAME 

:  EXP 

:  value 

:  TYPEJPEC 

:  source_position 
:  comments 


qua! if ied 


IS  INCLUDED  IN: 

QUAL  CONV 
EXP  VAL  EXP 
EXP"VAL~ 

EXP'EXP 

EXP“ 

G£NERAL_ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  QUALJONV): 
as_name 

(INHERITED  FROM  EXPJALJXP): 
as_exp 

(INHERITED  FROM  EXP_VAL): 
sm_value 

(INHERITED  FROM  EXPJXP): 
sm_exp_type 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ixjomments 
IS  THE  DECLARED  TYPE  OF: 


:  NAME 

:  EXP 

:  value 

:  TYPEJPEC 

:  sour ce_posit ion 
:  comments 


qua! if ied_al locator. as_qual if ied 


qual if 1ed_al locator 

IS  INCLUDED  IN: 

EXP  EXP 
EXP" 

GENERAL_ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 


OIAHA  Reference  Manual  Draft  Revision  4  Page  A-97 

DIANA  CROSS-REFERENCE  GUIDE 


(NODE  SPECIFIC): 

as  qualified 

( INNER ITED'FROM  EXPJXP): 
sm  exp  type” 

(INHERITED”FROM  ALL_SOURCE): 
lx_srcpos 
lx”comments 

*♦  raise 

IS  INCLUDED  IN: 

STM_WITH  NAME 
STM 

STM  ELEM 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  STM_WITH_NAME) : 

as_name  ”  :  NAME 

(INHERITED  FROM  ALLJOURCE): 

1x_srcpos  :  source_position 

1x”comments  :  comments 

**  RANGE 

CLASS  MEMBERS: 
range 
void 

range  attribute 
IS  INCLUDED  IN: 

DISCRETE  RANGE 
CONSTRAINT 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_type_spec 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
1x_comments 
IS  THE  DECLARED  TYPE  OF: 

comp_reo . as_range 
range_memper  sh  i  p .  as_'^ange 
REAL_CONSTRAINT.as_range 
SCALAR. sm_range 

**  range 

IS  INCLUDED  IN: 

RANGE 

DISCRETE_RANGE 
CONSTRAINT 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_expl  :  EXP 


:  TYPE_SPEC 

:  source_po5ition 
:  comments 


:  qualified 

:  TYPEJPEC 

:  source_position 
:  comments 
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as_exp2 

(INHERITED  FROM  RANGE): 
sm_type_spec 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


♦*  range_att»‘ibute 

IS  INCLUDED  IN: 

RANGE 

DISCRETE  RANGE 
CONSTRAINT 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 
as~exp 

as~used_name_id 
(INHERITED  FROM  RANGE): 
sm_type_spec 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


**  range_membership 

IS  INCLUDED  IN: 

MEMBERSHIP 
EXP_VAL  EXP 
EXP_VAL" 

EXP  EXP 
EXP" 

general_assoc 

ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_range 

(INHERITED  FROM  MEMBERSHIP): 
as_member sh i p_0D 

(INHERITED  FROM  EXP_VAL_EXP) : 
as_exp 

(INHERITED  FROM  EXP_VAL): 
sm  value 

(INHERITED~FROM  EXPJXP): 
sm  exp_type 

(INHERITED"FROM  ALLJOURCE): 
1x_srcpos 
lx  comments 


**  REAL 


CLASS  MEMBERS: 
float 


:  EXP 

:  TYPEJPEC 

:  source_position 
:  comments 


:  NAME 
:  EXP 

:  used_name_id 

:  TYPEJPEC 

:  source_position 
:  comments 


:  RANGE 

;  MEM8ERSHIP_0P 

:  EXP 

:  value 

:  TYPEJPEC 

:  source_position 
:  comments 
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fixed 

IS  INCLUDED  IN: 

SCALAR 
N0N_TASK 
FULL  TYPE  SPEC 
DERIVABLEjPEC 
TYPE_SPEC 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  accuracy 

(INHERITED'FROM  SCALAR): 
sni_range 
cd~imp1  size 

{ INHERITEO~FROM~NON_TASK) : 
sm  base_type 

(INHERITED“FROM  OERIVABLEJPEC) ; 
sm_derived 
sm  is  anonymous 


value 

RANGE 

Integer 

TYPEJPEC 

TYPEJPEC 

Boolean 


**  REAL  CONSTRAINT 


CLASS  MEMBERS: 

f loat_constraint 
f ixed_constraint 
IS  INCLUDED  IN: 

CONSTRAINT 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

■  sm_type_spec 
as~exp 
as'range 

(INHERITEO’FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


;  TYPE_SPEC 
:  EXP 
:  RANGE 

:  source_position 
:  comments 


**  record 


IS  INCLUDED  IN: 

UNCONSTRAINED_COMPOSITE 
UNCONSTRAINED 
NON  TASK 
FULL  TYPEJPEC 
OERIVABLEJPEC 
TYPEJPEC 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_discriminant_s  :  dscrmt_decl_s 

sm_representation  :  REP 

sm~comp_list  :  comp  list 

(INHERITED  FROM  UNCONSTRAINEDJOMPOSITE) : 
sm_is_l imited  :  Boolean 

sm_is_packed  :  Boolean 

(INHERITED  FROM  UNCONSTRAINED): 
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sni_size 

(INHERITED  FROM  N0N_TASK); 
sm  base_type 

(INHERITED~FROM  DERIVABLE_SPEC) : 
sm_deri ved 
sm~is  anonymous 


**  record  def 


IS  INCLUDED  IN: 

TYPE  OEF 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  comp_list 

(INHERITED'FROM  ALLJQURCE): 
lx_srcpos 
lx  comments 


**  record_rep 

IS  INCLUDED  IN: 

REP 

DECL 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_a1 ignment_clause 
as'comp  rep_s 

(INHERITED  FROM‘R£P): 
as  name 

(INHERITED~FR0M  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  RENAME_INSTANT 

CLASS  MEMBERS: 

renames_unit 
instantiation 
IS  INCLUDED  IN: 

UNIT_KIND 
UNIT_OESC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 

(INHERITED  FROM  ALL_SOURCE); 
1x_srcpos 
lx  comments 


EXP 

TYPEJPEC 

TYPEJPEC 

Boolean 


:  comp_list 

:  source_position 
:  comments 


:  ALIGNMENT_CLAUSE 
:  comp_rep_s 

:  NAME 

:  source_position 
:  comments 


:  NAME 

;  source_position 
:  comments 


**  renames  exc  dec! 
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ieit 


liir 


IS  INCLUDED  IN: 

SIMPLE  RENAME_OECL 

ID  DECL 

DECL 

ITEM 

ALL_DECL 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  SIMPLE_RENAME_DECL) : 

as  name  :  NAME 

(INHERITED'FROM  IO_DECL): 

as_source_name  :  SOURCE  NAME 

(INHERITED  FROM  ALL_SOURC£): 

lx_srcpos  :  source_position 

lx  comments  :  comments 


renames_obj_decl 


IS  INCLUDED  IN: 

SIMPLE_P.ENAME_DECL 

ID_DECL 

DECL 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  type  mark  name  :  NAME 

(INHERITED"FROM~SIMPLE_RENAME_DECL): 

as  name  :  NAME 


(INHERITEO'FROM  ID_DECL): 
as  source  name 


SOURCE  NAME 


(INHERITED  FROM  ALL_S0URCE): 
1x_srcpot 
lx  comments 


:  source_position 
:  comments 


renames  unit 


IS  INCLUDED  IN; 

RENAME_INSTANT 
UNIT_KINO 
UNIT_DESC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  RENAMEJNSTANT) : 
as_name 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


NAME 

source_position 

comments 


REP 


CLASS  MEMBERS: 
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void 

NAHE0_REP 
record_rep 
length~enutn_rep 
address 
IS  INCLUDED  IN: 

DECL 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  name 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx~comments 
IS  THE  DECLARED  TYPE  OF: 

record . sm_representation 

**  return 

IS  INCLUDED  IN: 

STM_WITH  EXP 
STM 

STM  ELEM 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  STM_WITH_EXP) : 
as  exp 

(INHERITED'FROM  ALLJOURC.E): 
lx_srcpos 
1 x”comments 


**  reverse 

IS  INCLUDED  IN: 

FOR_REV 
ITERATION 
ALL_SOURCE 
NODE  ATTRIBUTES; 

(INHERITED  FROM  FOR_REV): 
as_source_name 
as3discrete_range 
(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
Ix^comments 


**  SCALAR 

CLASS  MEMBERS: 

enumeration 

REAL 

integer 

float 


:  NAME 

:  source_position 
:  comments 


:  EXP 

:  source_position 
:  comments 


:  SOURCE  NAME 
:  DISCRETE_RANGE 

:  source_position 
:  comments 
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fixed 

IS  INCLUDED  IN: 

NON  TASK 
FULL  TYPEJPEC 
DERIVABLEJPEC 
TYPEJPEC 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
sm_range 
cd~imp1  size 

(INHERITED~FR0M"N0N_TASK) : 
sm  base_type 

(INHERITEO'FROM  DERIVABLEJPEC) 
sm_derived 
sm_is  anonymous 
IS  THE  DECLARED  TYPE  OF: 

scalar_s.as_list  [Seq  Of] 


**  scalar_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  list 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 
IS  THE  DECLARED  TYPE  OF: 

constrai ned_array . sm_i ndex 

se1ect_alt_pragma 

IS  INCLUDED  IN: 

TEST_CLAUSE_ELEM 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_pragrna 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_comments 

**  select_alternative 

IS  INCLUDED  IN: 

TESTJLAUSE 
TESTJLAUSEJLEM 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  TESTJLAUSE): 
as_exp 
as  stm  s 


:  RANGE 
:  Integer 

:  TYPEJPEC 

':  TYPEJPEC 
:  Boolean 


:  Seq  Of  SCALAR 

:  source_position 
:  comments 

subtype_s 


:  pragma 

:  source_position 
:  comments 


:  EXP 
:  stm  s 
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(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 

**  selected 

IS  INCLUDED  IN: 

NAME  VAL 
NAME“EXP 
NAME" 

EXP 

GENERAL  ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_designator 
(INHERITED  FROM  NAMEJAL): 
sm  value 

(INHERITED'FROM  NAMEJXP): 
as_name 
sm_exp_type 

(INHERITED  FROM  ALLJOURCE): 

1x_srcpos 
lx  comments 


**  select! ve_wa it 

IS  INCLUDED  IN: 

CLAUSES  STM 
STM 

STMJLEM 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  CLAUSES JTM): 

as_test_clause_ilem_s 

as_stm_s 

(INHERITED  FROM  ALLJOURCE): 

1 x_srcpos 
1 x_comments 

**  SEQUENCES 

CLASS  MEMBERS: 

alternat1ve_s 

variant_s 

use_pragma_s 

test_clause_elem_s 

stm_s 

soufce_name_s 

scalar_s 

pragma_s 

param_s 

name_s 

index  s 


:  source_position 
:  comments 


:  DESIGNATOR 

:  value 

:  NAME 
:  TYPEJPEC 

:  source_position 
:  comments 


:  test_clause_elem_s 
:  stm_s 

:  source_oo5ition 
:  comments 
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1 teffl_s 
exp_i 

enui_lUeral_s 

discfete_range_s 

general_assoc_s 

dscrtnt_dec1_s 

dec1_s 

contixt_elem_s 
coropltn_unit~s 
co(np_rep_s 
choice_s~ 
argument_id_s 
IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


short_circuit 

IS  INCLUDED  IN: 

EXP_VAL 

EXPJXP 

EXP 

GENERAL_ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_expl 
asjxp2 

as'short  circuit  op 
(INHERITEO'FROM  EXP_VAL)T 
sm  value 

(INHERITED"FR0M  EXPJXP): 
sni_exp_type 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  SHORTJIRCUITJP 

CLASS  MEMBERS: 

andjhen 
or  else 
IS  INCLUDED  IN: 

ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx_coniments 
IS  THE  DECLARED  TYPE  OF: 

short  circuit. as  short  ci 


:  source_position 
:  conments 


:  EXP 
:  EXP 

:  SHORT_CIRCUIT_OP 

:  value 

:  TYPEJPEC 

:  source_position 
:  comments 


:  source_position 
:  comments 

it_op 
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simple_rename_decl 

CLASS  MEMBERS: 

renames_obj_decl 
renames~exc~decl 
IS  INCLUDED  IN:" 

ID  DECL 

DECL 

ITEM 

ALL  DECL 
ALL~SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_name 

(INHERITED  FROM  ID_DECL): 

as_source_name 
(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


slice 

IS  INCLUDED  IN: 

NAME  EXP 
NAME" 

EXP 

GENERAL  ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  discrete_range 
(Inherited"from  namejxp): 
as_name 
sm  exp_type 

(INHERITE0"FR0M  A(L_SCURCE): 
lx_srcpos 
lx  comments 


SOURCE_NAME 

CLASS  MEMBERS: 

OBJECT_NAME 
LABEL  NAME 
UNIT_NAME 
TYPE_NAME 
void 

entry_id 

exception_id 

INIT_OBJtCT_NAME 

enum_l::eral 

iteration_id 
1abel_id 
block2loop_id 
NON  TASK  NAME 


;  NAME 

:  SOURCE_NAME 

:  source_position 
:  comments 


:  DISCRETE_RANG£ 

:  NAME 
:  TYPE_SPEC 

:  source_position 
:  comments 
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task_boc)y_icl 
type~id 
subtype_id 
private_type_id 
l_private_type_id 
VC_NAME 
number_id 
C0MP_NAME 
PARAM_NAME 
enutneration_id 
character_id 
SUBPROG_PACK_NAME 
generic'id 
variable_id 
constantjd 
component_id 
discriminant_id 
in_id 
out_id 
in_out_id 
SU6PR0G_NAME 
packaqe_id 
procecure_id 
operator_id 
function  id 
IS  INCLUDED  IN: 

DEF  NAME 
ALL‘S0URCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DEF_NAME): 

1x_syrnrep  : 

(INHERITED  FROM  ALLJOURCE): 

ix_srcpos  : 

lx_comments  : 

IS  THE  DECLARED  TYPE  OF: 

SUBUN IT_B0DY . as_source_name 
imp! icit_not_eq.sm_equal 
der  i  ved_subprog .  sin_deri  vabi  e 
F0R_RE V . ds_source_name 
8L0CK_L00P .  as_source_ndrne 
source_name_s.as_l ist  [Seq  Of 
ID_OECL.as_sourci_natiie 

**  source_name_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_list  : 

(INHERITED  FROM  ALL_SOURCE): 

1x_srcpos  : 

lx  comments  : 


symbol_rep 

source_position 

comments 


Seq  Of  SOURCE_NAME 

source_position 

comments 
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IS  THE  DECLARED  TYPE  OF: 

1 abe 1 ed . as_sou  r ce_name_s 
DSCRMT_PARAM_DECLTas_source 
ID  S  DECL.as  source  name  s 


**  STM 


CLASS  MEMBERS: 

labeled 
nul 1_stm 
abort 

STM  WITHJXP 
STM~WITH_NAME 
accept 
ENTRY  STM 

block'loop 

CLAUSESJTM 

terminate 

return 

delay 

STM_WITH_EXP_NAME 

case 

goto 

raise 

calljtm 

cond_entry 

timed_entry 

loop 

block 

if 

selective_wait 

ass ign 

code 

exit 

entry_cal 1 
procedure_cal 1 
IS  INCLUDED  IN: 

stmjlem 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 

b 1 ock_master . sm_stm 
exit.sm_stm 
LABEL_NAME.sm_stm 
labeled. as  stm 


♦*  STMJLEM 

CLASS  MEMBERS: 

STM 

stm_pragma 


name  s 


:  source_position 
:  comments 
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labeled 
nul 1_stm . 
abort 

STM  WITHJXP 
STM~WITH_NAME 
accept 
ENTRY  STM 

block"loop 

CLAUSESJTM 

terminate 

return 

delay 

STM_WITH_EXP_NAME 

case 

goto 

raise 

CALLJTM 

Cond_entry 

timed_entry 

loop 

block 

i  f 

selecti ve_wait 

assign 

code 

exit 

entry _cal 1 
procedure  call 
IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcoos  :  source_position 

lx~comrnents  :  comments 

IS  THE  DECLARED  TYPE  OF: 

stm_s.as_l ist  [Seq  Of] 

**  stm_pragma 

IS  INCLUDED  IN: 

STM  ELEM 

all"source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  pragma  :  pragma 

(INHERITED'FROM  ALL_S0URCE); 

lx_srcpos  :  source_position 

lx_comments  :  comments 

**  stm_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL  SOURCE 
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NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  list 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 

ENTRY_STM.as_Stm_sl 
.as~stm~s2 
accept. as_stm_s 
b1ock_body.as~stm_s 
loop.as_stm_s~ 
alternativeTas  stm  s 
TEST_CLAUSE.as~stm“s 
CLAUSES  STM. as  stm“s 


**  STM_WITH_EXP 

CLASS  MEMBERS: 

return 

delay 

stm_with_exp_name 

case 

assign 

code 

exit 

IS  INCLUDED  IN: 

STM 

STMJLEM 
ALL_S0URCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  exp 

( INNER  ITED'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  STM_WITHJXP_NAME 

CLASS  MEMBERS: 

assign 

code 

exit 

IS  INCLUDED  IN: 

STM_WITH_EXP 

STM 

STMJLEM 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  name 

(INHERITED'FROM  STM_WITH JXP) : 
as_exp 

(INHERITED  FROM  ALLJOURCE): 


:  Seq  Of  STM_ELEM 

:  source_position 
:  comments 


:  EXP 

:  source_position 
:  conments 


:  NAME 
:  EXP 
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lx_srcpos 

Ix'comments 

**  STM_WITH_NAME 

CLASS  MEMBERS: 
goto 
raise 
CALL_STM 
entry _call 
procedure  call 
IS  INCLUDED  IN: 

STM 

STM  ELEM 
ALL~SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  name 

(INHERITEO'FROM  ALL_SOURCE): 
lx_srcpos 
lx~comments 

**  string_l iteral 

IS  INCLUDED  IN: 

AGG  EXP 
EXPjXP 
EXP 

general  ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

lx  sytnrep 

(INHERITEO“FROM  AGGJXP): 
sm_discrete~range 

(INHERITED  FROM  EXPJXP): 
sm_exp_type 

(INHERITED  FROM  ALLJOURCE): 
1 x_srcpos 
lx  comments 
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:  source_position 
:  comments 


:  NAME 

:  source_position 
:  comments 


:  symbol _rep 

:  DISCRETEJANGE 

:  TYPEJPEC 

:  source_position 
:  comments 


**  stub 


IS  INCLUDED  IN: 

BODY 

UNIT  OESC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  :  source_position 

lx  comments  :  comments 


**  SUSP  ENTRY  HEADER 
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CLASS  MEMBERS: 

procedure_spec 
functiori_ipec 
entry 

IS  INCLUDED  IN: 

HEADER 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  paratn_s 

(INHERITED~FROM  ALLJOURCE): 
lx_srcpos 
lx~comments 

**  subprog_entry_dec1 

IS  INCLUDED  IN: 

NON  GENERIC  OECL 
UNIT  OECL 
ID_0ECL 
OECL 
ITEM 

ALL  OECL 
ALLjOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  NON_GENERIC_DECL) : 

as  unit  kind  :  UNIT  KIND 

(INHERITEO"FROM~UNIT_OECL): 

as  header  :  HEADER 

(INHERITEO'FROM  I0_0ECL): 

as  source_name  :  SOURCE  NAME 

(INHERITED'FROM  ALLJOURCE): 

Ixjrcpos  :  source_position 

Ixjominents  :  cornments 

**  SUBPROGJAME 

CLASS  MEMBERS: 

procedure_id 
operator_id 
function_id 
IS  INCLUDED  IN: 

SUBPROG  PACK  NAME 
NON  TASKJAME 
UNITJAME 
SOURCEJAME 
DEFJAME 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

siii_is_in1  ine  :  Boolean 

sm_interface  :  PREDEF  NAME 

(INHERITED  FROM  SUBPROG_PACK_NAME) : 

sm  unit  desc  :  UNIT  DESC 


:  param_s 

:  source_position 
:  comments 
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sm  address  :  EXP 

(INHERITED'FROM  NON_TASK_NAME ) : 

sm  spec  ~  “  :  HEADER 

(INHERITEO'FROM  UNIT_NAME): 

sm  first  :  DEF  NAME 

(INHERITEO'FROM  D£F_NAME): 

lx  symrep  '  :  symbol  rep 

(INHERITEO'FROM  ALL_SOURCE): 

lx_srcpos  '  :  source_position 

Ix'comments  :  comments 

**  SUBPROG_PACK_NAME 

CLASS  MEMBERS: 

SUBPROG_NAME 
package'id 
procedure_id 
operator_id 
function~id 
IS  INCLUDED  IN:  ' 

NON_TASK_NAME 
UNIT_NAME 
SOURCE  NAME 
DEF_NAME 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_unit_desc  :  UNIT_DESC 

sm'addriss  :  EXP  ' 

(INHERITEO'FROM  NON_TASK_NAME) : 

sm  spec  '  '  :  HEADER 

(INHERITEO'FROM  UNIT_NAME): 

sm  first  :  DEF  NAME 

(INHERITEO'FROM  DEF_NAME): 

lx  symrep  :  symbol  rep 

(INHERITEO'FROM  ALLJOURCE): 

lx_srcpos  '  :  source_position 

Ix'comments  :  comments 

**  subprogram_body 

IS  INCLUDED  IN: 

SUBUNIT  BODY 
ITEM 

ALL_DECL 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  header 

(INHERITEO'FROM  SUBUNIT_BODY) : 
as_source_name 
as'body 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 


:  HEADER 

:  SOURCE  NAME 
:  BODY 

:  source_position 
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1x_cominents 

**  subtype_al locator 

IS  INCLUDED  IN: 

EXP  EXP 
EXP” 

GENERAL  ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_subtype_indication 
sm”desig  type 

(INHERITED"FR0M  EXP_EXP): 
sm_exp_type” 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
1x”comments 


**  subtype_decl 

IS  INCLUDED  IN: 

ID  DECL 

DECL 

ITEM 

ALL  DECL 
ALL”SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_subtype  indication 
(INHERITED  FROM  ID^DECL): 

as  source_name 
(INHERITED'FROM  ALL_S0URCE): 
ix_srcpos 
lx  comments 


**  subtype_id 

IS  INCLUDED  IN: 

TYPE_NAME 
S0URCE_NAME 
DEF_NAME 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  TYPE_NAME): 
sm  type  spec 

(INHERITED”FR0M”DEF_NAME): 
lx  symrep 

(INHERITE0“FR0M  ALL_S0URCE): 
lx_srcpos 
lx  comments 


** 


:  comments 


:  subtype  indication 
:  TYPE_SPFC 

:  TYPE_SPEC 

:  source_position 
:  comments 


:  subtype_indication 

:  S0URCE_NAME 

:  source_position 
:  comments 


:  TYPE_SPEC 

;  symbol _rep 

:  source_position 
:  comments 


subtype_indication 
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IS  INCLUDED  IN: 

CONSTRAINED_DEF 
TYPE  DEF 

ALL  Source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  name  :  NAME 

(INHERITED'FROM  CONSTRAINED_DEF) : 

as  constraint  :  CONSTRAINT 

(INHERITED“FR0M  ALLJOURCE): 

lx_srcpos  ”  :  source_position 

1x~comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

subtype_a  n  ocator . as_subtype_i nd i cat i on 
discrete_subtype.as_subtype_indication 
subtype_dec 1 . as_sobtype_i ndTcat i on 
ARR_ACC_OER_DEFTas_subtype_i nd i cat i on 


**  subunit 


IS  INCLUDED  IN: 

ALL_DECL 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as__name 

as”subunit  body 
(INHERITED“FROM  ALLJOURCE )•: 
1x_srcpos 
1x~comments 


:  NAME 

:  SUBUNITJDDY 

:  source_position 
:  comments 


**  SUBUNIT  BODY 


CLASS  MEMBERS; 

subprogram_body 
task_body 
package  body 
IS  INCLUDED  IN:“ 

ITEM 

ALL  DECL 
ALL'SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_source_name 

as”body 

(INHERITED'FROM  ALLJOURCE): 
1x_srcpos 
lx”comments 
IS  THE  DECLARED  TYPE  OF: 

subunit. as  subunit  body 


:  SOURCE  NAME 
:  BODY 

:  source_position 
:  comments 


**  taskjody 


IS  INCLUDED  IN: 
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SUBUNIT_B00Y 

ITEM 

ALL  DECL 

all'source 

NODE  ATTRIBUTES: 

(INHERITED  FROM  SUBUNITJOOY): 
as_source_name 
as'body 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


**  task_body_id 

IS  INCLUDED  IN: 

UNIT_NAME 
SOURCE  NAME 
DEF  NAME 

all'source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

stn_type_spec 

sm_body 

(INHERITED  FROM  UNIT_NAME): 
sm  first 

(INHERITEO'FROM  OEF_NAME): 
lx  symrep 

(INHERITED~FROM  ALLJOURCE): 
lx_srcpos 
Ix'cotnments 


**  task_decl 

IS  INCLUDED  IN: 

ID_DECL 

DECL 

ITEM 

ALL_DECL 
ALLJOURCE 
NODE  ATTRIBUTES; 

(NODE  SPECIFIC): 

as  decl  s 

(INHERITE0“FR0M"I0_DECL): 

as  source  name 
(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx~comments 


♦*  task_spec 

IS  INCLUDED  IN; 

FULLJYPEJPEC 
DERIVABLE  SPEC 
TYPE  SPEC" 


:  SOURCE  NAME 
:  BODY 

:  source_position 
:  comments 


■:  TYPEJPEC 
:  BODY 

:  DEF_NAME 

:  symbol __rep 

;  source^position 
:  comments 


:  decl_s 

:  SOURCE_NAME 

;  source_position 
:  comments 
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NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_dec1_s 

sm~storage_size 

stn'size 

sm~address 

sin_body 

(INHERITED  FROM  OERIVABL£_SPEC) 
sin_derived 
sin_is_anonymous 


**  termi nate 

IS  INCLUDED  IN: 

STM 

STMJLEM 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
1x_srcpos 
lx  comments 


**  TEST_CLAUSE 

CLASS  MEMBERS: 

cond_clause 
select  alternative 
IS  INCLUDED  INT 

TEST  CLAUSE  ELEM 
ALL  SOURCE  “ 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_exp 
as~stm_s 

(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


**  TEST_CLAUSE_ELEM 

CLASS  MEMBERS: 

TEST_CLAUSE 
select_alt_pragma 
cond_cTausi 
select  alternative 
IS  INCLUDED  INT 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 
IS  THE  DECLARED  TYPE  OF: 

test  clause  elem  s.as  list 


:  dec!  s 
:  EXP  ■ 

:  EXP 
:  EXP 
:  BODY 

*:  TYPE_SPEC 
:  Boolean 


:  source_position 
:  comments 


;  EXP 
:  stm_s 

:  source_position 
:  comments 


:  source_position 
:  comments 

[Seq  Of] 
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**  test  clause  elem  s 


IS  INCLUDED  IN: 

SEQUENCES 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  list  :  Seq  Of  TEST  CLAUSE_ELEM 

(INHERITED~FROM  ALL_SOURCE): 

lx_srcpos  ~  :  source_position 

lx~comtnents  :  comments 

IS  THE  DECLARED  TYPE  OF: 


CLAUSES  STM. as  test  clause  elem  s 


**  timed  entry 


IS  INCLUDED  IN: 

ENTRY  STM 
STM 

STM  ELEM 

all'source 

•  NODE  ATTRIBUTES: 

(INHERITED  FROM  ENTRY_STM): 
as  stm  si 


as  stm  s2 

(INHERITED~FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


3tm_s 

stm”s 

source_position 

comments 


**  type_decl 


IS  INCLUDED  IN: 

I0_DECL 

DECL 

ITEM 

ALL_0ECL 
ALL_S0URCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_dscrmt_decl_s 

as_type_def 

(INHERITED  FROM  IO_OECL): 
as_source_name 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


:  dscrmt_decl  s 
:  TYPE_DEF 

:  SOURCE_NAME 

:  source_position 
:  comments 


**  TYPE_DEF 

CLASS  MEMBERS: 

enumeration_def 
record_def 
ARR_ACC_DER  DEF 
CONSTRAINED'DEF 
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void 

private_def 
1_private_def 
formal _dscrt_def 
f orma 1 ~f 1 oat_def 
forma l~fixed_def 
formal ~integer_def 
constrii ned_array _def 
derived_def'’ 
accessdef 

unconstrai ned_array_def 
subty pe_i nd i cat i on 
integer_def 
f ixed_dif 
float  def 
IS  INCLUDED  IN: 

ALL  SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  :  source_position 

1x~comments  :  comments 

IS  THE  DECLARES  TYPE  OF: 

type_decl .as_type_def 
OBJECT_DECL.as_type_def 


♦*  type_id 

IS  INCLUDED  IN: 

TYPE  NAME 
SOURCE  NAME 
DEF  NAME 

all"source 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  first  :  DEF  NAME 

(INHERITED~FROM  TYPE_NAME): 

sin_type  spec  :  TYPE_SPEC 

(INHERITED  FR0M"0EF_NAME) : 

lx  symrep  :  symbol _rep 

(INHERITEO'FROM  ALL_SOURCE): 

lx_srcpos  :  5ource_oosition 

lx  comments  :  comments 


**  type_membership 

IS  INCLUDED  IN: 

MEMBERSHIP 
EXP_VAL  EXP 
EXP_VAL“ 
EXPJXP 
EXP 

general_assoc 

ALL_SOURCE 
NODE  ATTRIBUTES: 
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(NODE  SPECIFIC): 
as  name 

(INHERITEQ-FROM  MEMBERSHIP): 
as  membership  op 

(INHERITEO'FROM  EXP_VAL_EXP) : 
as  exp 

(INHERITEO'FROM  EXPJAL): 
sm  value 

(INHERITEO'FROM  EXPJXP): 
sm  exp  type 

(INHERITEO'FROM  ALLJOURCE): 
1x_srcpos 
lx”comtnents 

**  TYPE_NAME 

CLASS  MEMBERS: 

type_id 
subtype_id 
pri vate_type_id 
1  pri vate_type_id 
IS  INCLUDED  IN; 

SOURCE  NAME 
DEE  NAME 
ALL'SOURCE 
•NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  type  spec 

( I NH  E  R I TE  D'F  ROM'DE  F  _NAME ) : 
lx  symrep 

(INHERITEO'FROM  ALLJOURCE): 

1 x_srcpos 
Ix'comments 


**  TYPEJPEC 

CLASS  MEMBERS: 

DERIVABLE  JPEG 

incomplete 

void 

uni versal_integer 
uni versal_rea1 
uni versal_f ixed 
FULLJYPE  SPEC 
PRIVATE  JPEC 
task  spec 
NONJASK 
private 
1  private 
SCALAR 
CONSTRAINED 
UNCONSTRAINED 
enumeration 
REAL 


:  NAME 

:  MEMBERSHIPJP 

:  EXP 

:  value 

:  TYPEJPEC 

:  source_position 
:  comments 


:  TYPEJPEC 

:  symbol _reo 

:  source_position 
:  comments 
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integer 

const rained_array 

constrai ned'access 

constrained'record 

UNCONSTRAINED_COMPOSITE 

access 

float 

fixed 

array 

record 

IS  THE  DECLARED  TYPE  OF: 

task_body_id.sm_type_spec 
PR  I VATE_SPEC . sm_type~spec 
subtype'all ocator . sm_des i g_type 
EXP_EXP . sm_exp_type 
USED_OBJECT . sm_exp_type 
NAME_EXP . sm_exp_type 
constrai ned_access . sm_des i g_type 
access . sm_dis ig_type 
i  ndex .  sin_type_spec 
array . sm_comp_type 
REAL_CONSTRAINT.sm_type_spec 
RANGE .  sin_type_spec 
NON_TASK.sm_base_type 
DERT\/ABLE_SPEC.sm_deri  ved 
TYPE_NAME7sm_type3pec 
OBJECT_NAME . sm_ob j_type 

**  UNCONSTRAINED 

CLASS  MEMBERS: 

UNCONSTRAINEO_COMPQSITE 

access 

array 

record 

IS  INCLUDED  IN: 

N0N_TASK 
FULL  TYPE_SPEC 
DERIVABLE  SPEC 
TYPEJPEC" 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm  size  :  EXP 

(INHERITED~FROM  N0N_TASK): 

sm_base  typi  :  TYPE  SPEC 

(INHERITED  FROM'OERIVABLE_SPEC) : 

sin_derived  :  TYPE_SPEC 

sm_is_anonymous  :  Boolean 

**  unconstrained_array_def 

IS  INCLUDED  IN: 

ARR_ACC  DER_DEF 
TYPE  DEF 
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ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  index  s  : 

(INHERITEO'FROM  ARR_ACC_DER_OEF) : 

as_subtype_Tndication  : 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  ~  : 

lx_coniments  : 

**  UNCONSTRAINED_COMPOSIT£ 

CLASS  MEMBERS: 
array 
record 
IS  INCLUDED  IN: 

UNCONSTRAINED 
NON  TASK 
FULL_TYPE_SPEC 
DERIVABLE_SPEC 
TYPEJPEC 
node  ATTRIBUTES: 

(NODE  SPECIFIC): 

stn_is_1  imited  : 

sin_is_packed  : 

(INHERITED  FROM  UNCONSTRAINED): 

stn  size  : 

(INHERITED'FROM  NONJASK): 
sm  base  type 

(INHtRrTEO'FROM^OERIVABLEJPEC): 

snt_derived  ~  : 

sm”i s_anonymous 

**  UNIT_DECL 

CLASS  MEMBERS: 

generic_decl 
NON_GENERIC_OECL 
subprog_entry_dec 1 
package  dec! 

IS  INCLUDED  IN:~ 

ID_DECL 

DECL 

ITEM 

ALL  DECL 
ALL'SOUfiCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_header 

(INHERITED  FROM  ID_DECL): 
as_soi.'rce  name 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  comments 


index_s 

subtype_indication 

source_position 

comments 


Boolean 

Boolean 

EXP 

TYPEJPEC 

TYPEJPEC 

Boolian 


:  HEADER 

:  SOURCE_NAME 

:  source_position 
:  comments 
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**  UNIT_DESC 

CLASS  MEMBERS: 

UNIT_KIND 

derived_subprog 

implicit  not  eq 

BODY 

void 

RENAME  INSTANT 
GENERlf_PARAM 
block_body 
stub 

renames_unit 
instantiation 
name_default 
no_difau1t 
box_default 
IS  INCLUDED  IN: 

ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 
1x_srcpos 
lx_coninients 
IS  THE  DECLARED  TYPE  OF: 

SUBPROG  PACK  NAME.sm  unit 


UNIT_KIND 

CLASS  MEMBERS: 
void 

rename_instant 

GENERIC_PARAM 
renames_unit 
instantiation 
name_default 
no_default 
box_default 
IS  INCLUDED  IN: 

UNIT  DESC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 
1x_srcpos 
lx_comments 
IS  THE  DECLARED  TYPE  OF: 

NON  GENERIC  DECL.as  unit 


*♦  UNIT_NAME 

CLASS  MEMBERS: 

NON_TASK_NAME 
task  body_id 
SUBPROG  PACK  NAME 


:  source_posi tion 
:  comments 

desc 


:  source_position 
:  comments 

kind 
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generic_i(j 
SUBPROG_NAME 
package'id 
procedure_id 
operator_id 
function~id 
IS  INCLUDED  IN:  ~ 

SOURCE_NAME 
DEF  NAME 
ALL"SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

Sfn  first 

(INHERITEO'FROM  0EF_NAME): 
lx  symrep 

(INHERITED'FROM  ALL_S0URCE): 
lx_srcpos 
1x~coinments 


**  universal_f ixed 

IS  INCLUDED  IN: 

TYPEJPEC 
NODE  ATTRIBUTES: 

**  universal_integer 

IS  INCLUDED  IN: 

TYPE  SPEC 
NODE  ATTRIBUTES: 

**  uni versal_real 

IS  INCLUDED  IN: 

TYPE_SPEC 
NODE  ATTRIBUTES: 


**  use 


IS  INCLUDED  IN: 

USE_PRAGMA 

DECL 

ITEM 

ALL_DECL 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  name  s 

( INHERITED~FROM“ALL_SOURCE) : 
lx_srcpos 
lx  comments 


:  DEF_NAME 

:  symbol _rep 

:  source_position 
:  comments 


:  name_s 

:  source_position 
:  comments 


**  USE  PRAGMA 
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CLASS  MEMBERS: 
use 

pragma 
IS  INCLUDED  IN: 

DECL 

ITEM 

ALL  DECL 
ALLjOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  ~  : 

1 x'comments  : 

IS  THE  DECLARED  TYPE  OF: 

use_pragma_s.as_list  [Seq  Of] 


**  use_pragma_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as_l ist 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx~commenf s 
IS  THE  DECLARED  TYPE  OF: 

with, as_use_pragma_s 


**  used^char 

IS  INCLUDED  IN: 

USED  OBJECT 

DESIGNATOR 

NAME 

EXP 

GENERAL_ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  USEO_OBJECT) : 
sm_exp_type 
sm~value 

(INHERITED  FROM  DESIGNATOR): 
sm_defn 
1 x~symrep 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
1x~comments 


**  USED_NAME 

CLASS  MEMBERS: 

•jsed_op 
used~name  id 


source_position 

comments 


Seq  Of  USE_PRAGMA 

source_position 

comments 


TYPEJPEC 

value 

DEF_NAME 
symbol _rep 

source_position 

comments 
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IS  INCLUDED  IN: 

DESIGNATOR 
NAME 
EXP 

GENERAL  ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DESIGNATOR): 
sm_defn 
lx  symrep 

(INHERITEO'FROM  ALLJOURCE): 
lx_srcpos 
lx~comments 
IS  THE  DECLARED  TYPE  OF: 

assoc. as_used_name 

**  used_name_1d 

IS  INCLUDED  IN: 

USED  NAME 
DESIGNATOR 
NAME 
EXP 

GENERAL_ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DESIGNATOR): 

sin_defn  :  DEF_NAME 

1x”symrep  :  symbol  rep 

(INHERITEO'FROM  ALLJOURCE): 

1x_srcpos  :  source_posUion 

lx~comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

attribute. as_used_name_id 
range_attribute.as_used_name_id 
pragma . as_used_name_id 

**  USEDJBJECT 

CLASS  MEMBERS: 

used_char 
used_object_id 
IS  INCLUDED  IN: 

DESIGNATOR 

NAME 

EXP 

GENERAL  ASSOC 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sffl_exp_type  ;  TYPEJPEC 

smjalue  :  value 

(INHERITED  FROM  DESIGNATOR): 

sm  defn  :  DEF  NAME 


:  DEFJAME 
:  symbol _rep 

:  source_position 
:  comments 
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lx  symrep 

(INHERITED'FROM  ALL_S0URCE): 
1x_srcpos 
lx~comments 


**  used_object_id 

IS  INCLUDED  IN: 

USED_OBJECT 

DESIGNATOR 

NAME 

EXP 

GENERAL_ASSOC 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  USED_08JECT) : 
stn_axp_type 
Sfn_value 

(INHERITED  FROM  DESIGNATOR): 
sm_defn 
1x_symrep 

(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
1x~comtnents 


**  used_op 

IS  INCLUDED  IN: 

USED  NAME 
DESIGNATOR 
NAME 
EXP 

GENERAL  ASSOC 
ALLJOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  DESIGNATOR): 
sm_defn 
lx  symreo 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


**  variable_decl 

IS  INCLUDED  IN: 

OBJECT  DECL 

EXP_DECL 

ID_S_OECL 

DECL 

ITEM 

ALL  DECL 
ALL"SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  OBJECTDECL) : 


:  symbol _rep 

:  source_position 
:  comments 


:  TYPE_SPEC 
:  value 

:  DEF_NAME 
:  symbol _rep 

:  source_position 
:  comments 


:  DEF_NAME 
:  symbol _r8p 

:  source_position 
:  comments 
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as  type_def 

(INHERITEO'FROM  EXP_DECL): 
as  exp 

(INHERITEO'FROM  ID_S_DECL): 

as  source  name  s 
(INHERITED'FROM  ALLJOURCE): 
lx_srcpos 
Ix'comments 


**  variable_id 

IS  INCLUDED  IN: 

VC  NAME 

inTt  0BJECT_NAME 
OBJECT_NAME 
SOURCE  NAME 
DEF  NAME 

all"source 

NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

sm_is_shared  : 

(INHERITED  FROM  VC_NAM£): 

sm_renames_ob j  : 

sm'address  : 

(INHERITED  FROM  INIT_OBJECT_NAME) 
sm  init  exp  ~  ~  : 

(INHERITED"FR0M*0BJECT_NAME) : 

sm  obj  type  ”  : 

(INHERITEO'FROM  DEF_NAME): 

lx  symrep  : 

(INHERITEO'FROM  ALLJOURCE): 

lx_srcpos  : 

lx  comments  : 


♦*  variant 

IS  INCLUDED  IN: 

VARIANTJLEM 
ALLJOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_choice_s 
as  comp  iTst 

(INHERITED'FR0M~ALL_S0URCE): 

lx_srcpos 

Ix'comments 


♦*  VARIANTJLEM 

CLASS  MEMBERS: 

variant 

variant  pragma 
IS  INCLUDED  IN:~ 

ALL  SOURCE 


TYPEJEF 

EXP 

source_name_s 

source_position 

comments 


Boolean 

Boolean 

EXP 

’exp 

TYPEJPEC 

symbol_reP' 

source_position 

comments 


choice_s 

comp_lTst 

source_position 

comments 
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NODE  ATTRIBUTES: 

(INHERITED  FROM  ALL_SOURCE): 

lx_srcpos  ~  :  source_position 

Ix'conments  :  comments 

IS  THE  DECLAREO  TYPE  OF: 

variant_s.as_list  [Seq  Of] 


VARIANT_PART 

CLASS  MEMBERS: 

wariant_part 

void 

IS  INCLUDED  IN: 

ALL_SOURCE 
NODE  ATTRIBUTES: 

(INHERITED  FROM  ALLJOURCE): 

lx_srcpos  ~  :  source_position 

1x_comments  :  comments 

IS  THE  DECLARED  TYPE  OF: 

comp_l ist.as_variant  part 


variant_part 

IS  INCLUOED  IN: 

VARIANT  PART 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_name  :  NAME 

as~variant_s  :  variant  s 

(INH£RITED"FROM  ALLJOURCE): 

lx_srcpos  :  source_position 

lx~comments  :  comments 

**  variant_pragma 

IS  INCLUDED  IN: 

VARIANTJLEM 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_pragma 

(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
1x_comments 

*♦  variant_s 

IS  INCLUDED  IN: 

SEQUENCES 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as  list  :  Seq  Of  VARIANT  ELEM 


:  pragma 

:  source_position 
:  comments 
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(INHERITED  FROM  ALLJOURCE): 
lx_srcpos 
lx  connents 
IS  THE  DECLARED  TYPE  OF: 

variant_part.as_var1ant  s 


**  VC_NAME 

CUSS  MEMBERS: 

var1able_1d 
constant~id 
IS  INCLUDED  IN:  ~ 

INIT  OBJECT  NAME 
OBJECT_NAME~ 

SOURCE  NAME 
0EF_NAME 
ALL_SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

siii_renames_obj  : 

sm^address”  : 

(INHERITED  FROM  INIT_QBJECT_NAME) 
sm  init  exp  : 

( I NHE  R I TE  0~F  ROM~OB J  E  CT_NAME ) : 

sm  obj_type  : 

(INHERITED'FROM  DEF_NAME): 

lx  symrep  ~  : 

(INHERITE0"FR0M  ALLJOURCE): 

lx_srcpos  ~  : 

lx~comments  : 


**  void 


IS  INCLUDED  IN: 

PREDEF_NAME 

COMP_REP_ELEM 

ALIGNMENT_CLAUSE 

ALL  DECL 

BODY 

UNIT_KIND 

NAME 

ITERATION 

SOURCE_NAME 

TYPE_SPEC 

TYPE  OEF 

VARIANT  PART 

REP 

RANGE 

CONSTRAINT 

EXP 

OEF_NAME 
ALL_SOURCE 
UNIT  DESC 
DECL“ 


source_position 

comments 


Boolean 

EXP 

EXP 

TYPE_SPEC 

symbol _rep 

source_position 

comments 
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DISCRETE  RANGE 
GENERAL  ASSOC 
ITEM 

NODE  ATTRIBUTES: 

(INHERITED  FROM  REP): 
as  name 

(INHERITED'FROM  RANGE): 
sm  type_spec 

(INHERITED  FROM  OEFJAME): 
lx  symrep 

(INHERITEO'FROM  ALL_SOURCE): 
1x_srcpos 
lx  comments 


**  while 

IS  INCLUDED  IN: 

ITERATION 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 
as  exp 

(INHERITED'FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


**  with 


IS  INCLUDED  IN: 

CONTEXT  ELEM- 
ALL  SOURCE 
NODE  ATTRIBUTES: 

(NODE  SPECIFIC): 

as_name_s 
as~use_pragma  s 
(INHERITED  FROM  ALL_SOURCE): 
lx_srcpos 
lx  comments 


:  NAME 

:  TYPEJPEC 

:  symbol _rep 

:  source_position 
:  comments 


:  EXP 

:  source_position 
:  comments 


:  name_s 
:  use_pragma_s 

:  source_posit1on 
:  comments 
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